[{"author": "Julian Reschke", "text": "

Guten Morgen, Mark :-)

", "time": "2022-07-28T17:31:36Z"}, {"author": "Lucas Pardue", "text": "

@mnot did you watch the Neighbours finale? :cry:

", "time": "2022-07-28T17:32:09Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2022-07-28T17:32:32Z"}, {"author": "Justin Richer", "text": "

they like big bells and they cannot lie

", "time": "2022-07-28T17:32:46Z"}, {"author": "Alan Frindell", "text": "

Mark's floating head on dark background strikes me as some kind of theater of the absurd

", "time": "2022-07-28T17:32:50Z"}, {"author": "Jonathan Hoyland", "text": "

So I always thought the floating head effect was caused by the time of day, but it must be day, surely?

", "time": "2022-07-28T17:33:47Z"}, {"author": "Matt Joras", "text": "

I think this is the third of fourth appearance of said disembodied head and it never gets old.

", "time": "2022-07-28T17:33:57Z"}, {"author": "Wendy Seltzer", "text": "


", "time": "2022-07-28T17:34:17Z"}, {"author": "Eric Orth", "text": "

It is near lunchtime where I am, but I did not have lunch yet. Therefore I did not have a good lunch just now.

", "time": "2022-07-28T17:34:20Z"}, {"author": "Jonathan Hoyland", "text": "

But your audio is separated from your video by at least a second

", "time": "2022-07-28T17:34:34Z"}, {"author": "Jonathan Hoyland", "text": "

What happened to Vienna?

", "time": "2022-07-28T17:35:20Z"}, {"author": "Martin Thomson", "text": "

Jonathan Hoyland said:


What happened to Vienna?


It's still there, last I checked.

", "time": "2022-07-28T17:35:36Z"}, {"author": "Lucas Pardue", "text": "

can't here Mike

", "time": "2022-07-28T17:39:05Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2022-07-28T17:39:12Z"}, {"author": "Lucas Pardue", "text": "

now better

", "time": "2022-07-28T17:39:13Z"}, {"author": "Mark Nottingham", "text": "

Alan - it may have something to do with it being 3:30am HERE :)

", "time": "2022-07-28T17:39:15Z"}, {"author": "David Schinazi", "text": "

Hello fellow enthusiasts, I will be your Jabber scribe for this session. This doesn't have anything to do with Jabber any more; if you want a text comment to be relayed at the microphone, prefix it with \"mic:\" and I will repeat it

", "time": "2022-07-28T17:39:19Z"}, {"author": "Mark Nottingham", "text": "

David: That's a macro, isn't it?

", "time": "2022-07-28T17:39:59Z"}, {"author": "David Schinazi", "text": "

That's a good idea

", "time": "2022-07-28T17:40:30Z"}, {"author": "Ted Hardie", "text": "

Don't we need an fqdn, not a single label?

", "time": "2022-07-28T17:41:55Z"}, {"author": "Tommy Pauly", "text": "

Yes, it needs to be an FQDN

", "time": "2022-07-28T17:43:52Z"}, {"author": "Alan Frindell", "text": "

Mark Nottingham said:


Alan - it may have something to do with it being 3:30am HERE :)


Nothing but empathy.

", "time": "2022-07-28T17:46:00Z"}, {"author": "Lucas Pardue", "text": "

you lose QUIC today when you try to use it and the server says no because Alt-Svc is broken

", "time": "2022-07-28T17:46:24Z"}, {"author": "Martin Thomson", "text": "

I always hear the ORANGES frame

", "time": "2022-07-28T17:47:55Z"}, {"author": "Jonathan Hoyland", "text": "

I am so down for H3 ORIGIN

", "time": "2022-07-28T17:48:16Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2022-07-28T17:48:17Z"}, {"author": "Martin Thomson", "text": "

I had the same thought as @Mark Nottingham there, but I can't think of a way it will interact. Yet.

", "time": "2022-07-28T17:49:15Z"}, {"author": "Nick Sullivan", "text": "

I support WGLC for H3 ORIGIN

", "time": "2022-07-28T17:49:35Z"}, {"author": "Lucas Pardue", "text": "

+1 david

", "time": "2022-07-28T17:49:50Z"}, {"author": "Martin Thomson", "text": "

Did someone say \"cookies\"? I missed lunch.

", "time": "2022-07-28T17:50:29Z"}, {"author": "David Schinazi", "text": "

Should I line up a question about the cookies?

", "time": "2022-07-28T17:50:34Z"}, {"author": "Martin Thomson", "text": "

@David Schinazi Agenda is tight, so maybe not

", "time": "2022-07-28T17:50:54Z"}, {"author": "Jonathan Hoyland", "text": "

@MeetEcho please can we realign the camera

", "time": "2022-07-28T17:50:57Z"}, {"author": "Alan Frindell", "text": "

Martin Thomson said:


Did someone say \"cookies\"? I missed lunch.


Gotta wait for the snack break ;(

", "time": "2022-07-28T17:51:19Z"}, {"author": "Jonathan Hoyland", "text": "


", "time": "2022-07-28T17:51:23Z"}, {"author": "Martin Thomson", "text": "

For issue 1939, it should be possible to check for /\\.(?:[0-9]+|0x[0-9a-f]+)$/ as that is how it is done in the WhatWG URL spec.

", "time": "2022-07-28T17:54:57Z"}, {"author": "David Benjamin", "text": "

For folks who had been paying attn to the DNS|IP issue before, this is a newer criteria than the old WHATWG spec and the RFC3986 formulation, which looked more like \"try to parse as IPv4, otherwise it's DNS\". That one is rather hairy, but it turns out to be undesirable for a lot of reasons anyway. This new one is nice and simple.

", "time": "2022-07-28T17:57:20Z"}, {"author": "David Benjamin", "text": "

(Turns out it's a problem for systems if \"a.\" is a DNS name while but \"\" is an IP address.)

", "time": "2022-07-28T17:58:00Z"}, {"author": "Jonathan Hoyland", "text": "

Esp. if you have to account for the ignored leap seconds.

", "time": "2022-07-28T18:00:34Z"}, {"author": "Martin Thomson", "text": "

I would point out that the \"human-friendly\" date is not always that friendly. Not all of us can translate from UTC to our current time zone so easily.

", "time": "2022-07-28T18:01:53Z"}, {"author": "Martin Thomson", "text": "

ISO -> RFC 3339 profile

", "time": "2022-07-28T18:02:16Z"}, {"author": "Tommy Pauly", "text": "

Agreed with mt

", "time": "2022-07-28T18:02:30Z"}, {"author": "Tommy Jensen", "text": "

Prefer int as well, the tools may want to present some other date format than the one we choose, and unaware tools are not worth optimizing for at the expense of minor parsing improvement for everyone

", "time": "2022-07-28T18:04:04Z"}, {"author": "Erik Nygren", "text": "

Will either minimize the likelihood of y2038 implementation bugs?

", "time": "2022-07-28T18:05:00Z"}, {"author": "Martin Thomson", "text": "

A controversial suggestion: HTTP will probably need a date that is before $now. What if we set a later epoch than 1970?

", "time": "2022-07-28T18:05:31Z"}, {"author": "Alex Chernyakhovsky", "text": "

if we go with int, will there be some tag so tools know it's representing a date since epoch...?

", "time": "2022-07-28T18:06:12Z"}, {"author": "Martin Thomson", "text": "

@Alex Chernyakhovsky yes. \"@\" I believe.

", "time": "2022-07-28T18:06:28Z"}, {"author": "Alex Chernyakhovsky", "text": "

otherwise will tools be expected to use heuristics to show a tooltip or whatever to developers?

", "time": "2022-07-28T18:06:30Z"}, {"author": "Martin Thomson", "text": "

As in Sf-Date: @1235634654

", "time": "2022-07-28T18:06:47Z"}, {"author": "Tommy Pauly", "text": "

Right, the tools can just always show it in your current TZ as little tip or interpretation or something

", "time": "2022-07-28T18:06:52Z"}, {"author": "Lucas Pardue", "text": "

set Epoch to RFC 9110 publish time

", "time": "2022-07-28T18:07:07Z"}, {"author": "Erik Nygren", "text": "

would that then be negative for old web pages last-modified in the 1990s?

", "time": "2022-07-28T18:08:04Z"}, {"author": "Justin Richer", "text": "

I thought it was rendered with the \"@\" prefix?

", "time": "2022-07-28T18:08:12Z"}, {"author": "Alex Chernyakhovsky", "text": "

@mit that seems great

", "time": "2022-07-28T18:08:14Z"}, {"author": "Alex Chernyakhovsky", "text": "

er, @mt :)

", "time": "2022-07-28T18:08:26Z"}, {"author": "David Schinazi", "text": "

MIT is different

", "time": "2022-07-28T18:08:38Z"}, {"author": "Lucas Pardue", "text": "

the web epoch then :D

", "time": "2022-07-28T18:08:42Z"}, {"author": "Alex Chernyakhovsky", "text": "

yes, but finger macros are hard to fix

", "time": "2022-07-28T18:08:46Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

Alex Chernyakhovsky said:


yes, but finger macros are hard to fix


so true

", "time": "2022-07-28T18:09:05Z"}, {"author": "Martin Thomson", "text": "

Erik Nygren said:


would that then be negative for old web pages last-modified in the 1990s?


Awkward, yeah, but you can always pretend they were modified last year. The cost of that is ...fine.

", "time": "2022-07-28T18:09:33Z"}, {"author": "David Benjamin", "text": "

I strongly prefer the @12345678 formulation. These values will be parsed by receivers far more than they'll be eyeballed by humans. We've had years of experience with the problems of mis-optimizing formats for the wrong thing. Let's not continue this and add another one.

", "time": "2022-07-28T18:10:18Z"}, {"author": "Justin Richer", "text": "


", "time": "2022-07-28T18:11:19Z"}, {"author": "David Schinazi", "text": "

@DavidBen want me to relay that?

", "time": "2022-07-28T18:11:23Z"}, {"author": "Tommy Pauly", "text": "

Agreed with DavidBen

", "time": "2022-07-28T18:11:30Z"}, {"author": "Erik Nygren", "text": "

Is there a reason a date would be integer sections and not have millisecond or microsecond resolution as an option?

", "time": "2022-07-28T18:11:30Z"}, {"author": "Justin Richer", "text": "

whoops, don't use that key pls

", "time": "2022-07-28T18:11:30Z"}, {"author": "Annabelle Backman", "text": "


", "time": "2022-07-28T18:12:51Z"}, {"author": "Julian Reschke", "text": "


", "time": "2022-07-28T18:14:03Z"}, {"author": "Lucas Pardue", "text": "

digest spec is with our AD, so no updates :)

", "time": "2022-07-28T18:17:05Z"}, {"author": "David Schinazi", "text": "

Clarification question: are the normalized fields sent next to the signature, or the original ones pre-normalization?

", "time": "2022-07-28T18:20:54Z"}, {"author": "Julian Reschke", "text": "

...field values...

", "time": "2022-07-28T18:25:59Z"}, {"author": "Jonathan Hoyland", "text": "

Can you have optional but mandatory-to-implement fields?

", "time": "2022-07-28T18:31:00Z"}, {"author": "Jonathan Hoyland", "text": "

i.e. can we make sure that an implementation that doesn't support SignatureContext is clearly non-spec compliant?

", "time": "2022-07-28T18:32:04Z"}, {"author": "Lucas Pardue", "text": "

justin: in server push, the server synthesizes a request and sends it to the client. If it signs that request, and the client verification of that signature fails, would this spec specify any behaviour to take? For instance, should the client reject the subsequent pushed response that relates to the failed request

", "time": "2022-07-28T18:35:00Z"}, {"author": "Justin Richer", "text": "

short version: we know about XMLDsig and aren't repeating those same mistakes here. :)

", "time": "2022-07-28T18:35:57Z"}, {"author": "Justin Richer", "text": "

@Jonathan: no, different applications are going to have completely different ideas of what needs to be signed. An implementation that doesn't use the \"context\" parameter just ... doesn't use it. If a library doesn't let oyu send that parameter then you can't use that library in that application because it's not fully compliant.Libraries should support all the optional parameters here.

", "time": "2022-07-28T18:37:18Z"}, {"author": "David Benjamin", "text": "

(Apologies, latency was very high so it took me several RTTs to even realize we were talking concurrently! :-/ )

", "time": "2022-07-28T18:38:16Z"}, {"author": "Darrel Miller", "text": "

I would be happy to provide feedback

", "time": "2022-07-28T18:38:34Z"}, {"author": "Jonathan Hoyland", "text": "

@Justin In which case, would the signature be different with \"\" vs omitted? As in, if someone _is_ using SignatureContext with an empty string, would it be distinct from someone not using it at all?

", "time": "2022-07-28T18:39:38Z"}, {"author": "Jonathan Hoyland", "text": "

(From what was said, I assume so, but I'm just trying to make sure.)

", "time": "2022-07-28T18:40:08Z"}, {"author": "Darrel Miller", "text": "

Sorry, to be more clear. I would be happy to provide feedback and contribute to the Query effort.

", "time": "2022-07-28T18:40:14Z"}, {"author": "Tommy Pauly", "text": "

Thanks Darrel!

", "time": "2022-07-28T18:40:24Z"}, {"author": "Darrel Miller", "text": "

Can I suggest avoiding the term \"chunk\" as it will be confused by some with chunked transfer encoding.

", "time": "2022-07-28T18:45:20Z"}, {"author": "Martin Thomson", "text": "

try capsule, frame, message, datagram, or packet

", "time": "2022-07-28T18:47:43Z"}, {"author": "David Schinazi", "text": "

, parcel, MSS, ...

", "time": "2022-07-28T18:48:30Z"}, {"author": "Martin Thomson", "text": "

I don't think that Upload-Incompete is interoperable.

", "time": "2022-07-28T18:48:30Z"}, {"author": "David Schinazi", "text": "


", "time": "2022-07-28T18:48:37Z"}, {"author": "Justin Richer", "text": "

@lucas I copied your text above to issue #2144

", "time": "2022-07-28T18:48:42Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2022-07-28T18:48:48Z"}, {"author": "Darrel Miller", "text": "

I think this is an interesting problem to solve. Microsoft have numerous APIs where we have attempted to address this problem.

", "time": "2022-07-28T18:49:37Z"}, {"author": "Lucas Pardue", "text": "

Cloudflare uses other versions of tus successfully for allowing user uploads for some products

", "time": "2022-07-28T18:49:48Z"}, {"author": "Lucas Pardue", "text": "

I support trying to solve the problem in a more interoperable way

", "time": "2022-07-28T18:50:21Z"}, {"author": "David Schinazi", "text": "

Lucas would you like me to relay that at the mic

", "time": "2022-07-28T18:50:43Z"}, {"author": "Martin Thomson", "text": "

A better design, to my mind, would be a 104 response that includes a new resource where uploads can be resumed.

", "time": "2022-07-28T18:50:44Z"}, {"author": "Lucas Pardue", "text": "

no thanks david

", "time": "2022-07-28T18:50:53Z"}, {"author": "Martin Thomson", "text": "

The client-selected token worries me.

", "time": "2022-07-28T18:51:04Z"}, {"author": "Tommy Pauly", "text": "

Agreed. The details have issues. But seems like a good problem to solve, as an individual here.

", "time": "2022-07-28T18:51:26Z"}, {"author": "Martin Thomson", "text": "

Yeah, I don't see a problem with this being adopted.

", "time": "2022-07-28T18:51:42Z"}, {"author": "Lucas Pardue", "text": "

FWIW the folks behind tus v1 are onboard with what change control in IETF means

", "time": "2022-07-28T18:52:11Z"}, {"author": "Julian Reschke", "text": "


", "time": "2022-07-28T18:52:49Z"}, {"author": "Kazuho Oku", "text": "

+1 to adopt.104 design is beautiful but potential downside would be that we cannot use HTTP/1.1 (due to broken intermediaries).

", "time": "2022-07-28T18:52:54Z"}, {"author": "Julian Reschke", "text": "

...we should work on this

", "time": "2022-07-28T18:52:59Z"}, {"author": "Lucas Pardue", "text": "

can we call it \"Chonked\" upload, since this is intended for largish resources?

", "time": "2022-07-28T18:53:53Z"}, {"author": "Martin Thomson", "text": "

@Kazuho Oku good point. Though maybe if the 104 only carried a link relation, the upload resource could be identified in a HEAD request if the client missed or couldn't receive the 104.

", "time": "2022-07-28T18:54:07Z"}, {"author": "David Schinazi", "text": "

Lucas: lol

", "time": "2022-07-28T18:54:18Z"}, {"author": "Mark Nottingham", "text": "

1xx also isn't available in some frameworks (server and client side). Not a dealbreaker, but some friction.

", "time": "2022-07-28T18:54:52Z"}, {"author": "Darrel Miller", "text": "

Lucas: +100

", "time": "2022-07-28T18:55:24Z"}, {"author": "Julian Reschke", "text": "

I like the idea of having a useful protocol that would phush frameworks/libs to support 1xx

", "time": "2022-07-28T18:56:11Z"}, {"author": "Mark Nottingham", "text": "

That would be good too.

", "time": "2022-07-28T18:57:38Z"}, {"author": "Tommy Jensen", "text": "

Sad social side effects of the mentioned incorrect specificity: https://splinternews.com/how-an-internet-mapping-glitch-turned-a-random-kansas-f-1793856052

", "time": "2022-07-28T18:57:52Z"}, {"author": "Justin Richer", "text": "

+1 to HTTP Chonks

", "time": "2022-07-28T19:01:34Z"}, {"author": "Martin Thomson", "text": "

Anyone looking to understand the limitations involved should read Section 13.5 of RFC 6772 (I'm listed as author on that document, but that is the only section I wrote).

", "time": "2022-07-28T19:06:56Z"}, {"author": "Martin Thomson", "text": "

To David's point, a very narrow domain of applicability might (I still say might) help. Maybe even a lot.

", "time": "2022-07-28T19:07:34Z"}, {"author": "Martin Thomson", "text": "

Fundamentally, this is not going to address the problem of bad data.

", "time": "2022-07-28T19:08:13Z"}, {"author": "Martin Thomson", "text": "

Bad data is a baseline fact of geolocation databases.

", "time": "2022-07-28T19:08:28Z"}, {"author": "David Schinazi", "text": "

+1 to MT about applicability domain. This might (again might) be a way to build something safe

", "time": "2022-07-28T19:08:38Z"}, {"author": "Martin Thomson", "text": "

That point from Brad was a good one, though I still remain hesitant to do something we don't understand the privacy properties of here.

", "time": "2022-07-28T19:09:12Z"}, {"author": "Martin Thomson", "text": "

I find it hard to believe that simple traffic analysis won't reveal that the MASQUE server is a MASQUE server

", "time": "2022-07-28T19:11:20Z"}, {"author": "Tommy Pauly", "text": "

Agreed with mt... I'm not sure if hidden proxies are really going to be viable. Just be public about it.

", "time": "2022-07-28T19:11:49Z"}, {"author": "Alex Chernyakhovsky", "text": "

possible, but that doesn't immediately suggest all masque servers should be willing to advertise they are masque servers

", "time": "2022-07-28T19:11:58Z"}, {"author": "Martin Thomson", "text": "

I can see a way to hide certain resources, but not the fact that it is a MASQUE proxy

", "time": "2022-07-28T19:12:18Z"}, {"author": "Jonathan Hoyland", "text": "

@MeetEcho can we adjust the camera please.

", "time": "2022-07-28T19:12:25Z"}, {"author": "Lucas Pardue", "text": "

can we not call it MASQUE please, I fear that will spook the folks trying to wrap their head around privacy proxies

", "time": "2022-07-28T19:12:26Z"}, {"author": "Jonathan Hoyland", "text": "


", "time": "2022-07-28T19:12:41Z"}, {"author": "Tommy Pauly", "text": "

Yeah I could see it more for the specific resources.

", "time": "2022-07-28T19:12:49Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2022-07-28T19:13:52Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

Gonna need a ntwice.

", "time": "2022-07-28T19:14:07Z"}, {"author": "Julian Reschke", "text": "


", "time": "2022-07-28T19:15:31Z"}, {"author": "Martin Thomson", "text": "

I would call it \"spontaneous HTTP client authentication\"

", "time": "2022-07-28T19:18:46Z"}, {"author": "Martin Thomson", "text": "

exported authenticators, oh yeah

", "time": "2022-07-28T19:19:07Z"}, {"author": "Justin Richer", "text": "

this feels like Token Binding but spicy

", "time": "2022-07-28T19:19:17Z"}, {"author": "Jonathan Hoyland", "text": "

Yeah, this is basically EAs without a CertificateRequest

", "time": "2022-07-28T19:19:27Z"}, {"author": "Tommy Pauly", "text": "

\"Spicy Binding\"

", "time": "2022-07-28T19:19:42Z"}, {"author": "Alan Frindell", "text": "

frames also hop-by-hop

", "time": "2022-07-28T19:20:07Z"}, {"author": "Jonathan Hoyland", "text": "

There are clients that do that as well :face_palm:

", "time": "2022-07-28T19:20:37Z"}, {"author": "Martin Thomson", "text": "

Spontaneous Client HTTP Authentication version 1 has a great acronym: SCHA-1

", "time": "2022-07-28T19:20:46Z"}, {"author": "Mark Nottingham", "text": "

I have to step outside for a moment; my breakfast is being delivered.

", "time": "2022-07-28T19:21:37Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2022-07-28T19:21:43Z"}, {"author": "Tommy Pauly", "text": "

What's for breakfast?

", "time": "2022-07-28T19:22:04Z"}, {"author": "Nick Sullivan", "text": "

Certificate frame relies on exported authenticators (RFC 9261), which doesn't support spontaneous client auth.

", "time": "2022-07-28T19:22:17Z"}, {"author": "Jonathan Hoyland", "text": "

I think it's worth working on the client auth problem, even if we don't go with this exact solution

", "time": "2022-07-28T19:23:10Z"}, {"author": "Nick Sullivan", "text": "

@David happy to talk through the certificate frame doc, it's less scary than it sounds and doesn't require X.509, just a TLS certificate message which can be a raw public key.

", "time": "2022-07-28T19:23:24Z"}, {"author": "Ted Hardie", "text": "

Did they consider calling it \"side channel\", just to keep it clear?

", "time": "2022-07-28T19:24:12Z"}, {"author": "Tommy Pauly", "text": "


", "time": "2022-07-28T19:24:23Z"}, {"author": "Martin Thomson", "text": "

So far, all I've heard is \"Google has some proprietary extensions to HTTP/2 and plans to make some proprietary extensions to HTTP/3\"

", "time": "2022-07-28T19:24:59Z"}, {"author": "Julian Reschke", "text": "


", "time": "2022-07-28T19:25:20Z"}, {"author": "Mark Nottingham", "text": "


", "time": "2022-07-28T19:25:22Z"}, {"author": "Alejandro Sede\u00f1o", "text": "


", "time": "2022-07-28T19:29:29Z"}, {"author": "Tommy Pauly", "text": "

The extension point is new frame types, we already have the ability to extend

", "time": "2022-07-28T19:29:48Z"}, {"author": "Erik Nygren", "text": "

I can see this useful as well, eg for load feedback reporting.

", "time": "2022-07-28T19:32:01Z"}, {"author": "Martin Thomson", "text": "

@Alan Frindell a generic capability that enabled access to writing frames would ALSO be generic, all it requires is that someone write the code in stacks

", "time": "2022-07-28T19:32:02Z"}, {"author": "Tommy Pauly", "text": "

mt, exactly

", "time": "2022-07-28T19:32:18Z"}, {"author": "Tommy Pauly", "text": "

Write a load feedback report frame

", "time": "2022-07-28T19:32:27Z"}, {"author": "Lucas Pardue", "text": "

the Server-Timing response field is a good example of actual framework

", "time": "2022-07-28T19:32:41Z"}, {"author": "Lucas Pardue", "text": "

this sounds like a ++ to that scope and capability

", "time": "2022-07-28T19:32:58Z"}, {"author": "Martin Thomson", "text": "

I was not clear enough: I think that this is harmful.

", "time": "2022-07-28T19:33:05Z"}, {"author": "Alan Frindell", "text": "

Last I heard, no one wanted to change their HTTP/2 stacks

", "time": "2022-07-28T19:33:09Z"}, {"author": "Martin Thomson", "text": "

mildly so, but still

", "time": "2022-07-28T19:33:13Z"}, {"author": "Matt Joras", "text": "

The bar for writing a new frame is pretty high. The bar for a user adding new \"metadata\" is much lower

", "time": "2022-07-28T19:33:14Z"}, {"author": "Lucas Pardue", "text": "

disagree matt :)

", "time": "2022-07-28T19:33:39Z"}, {"author": "Martin Thomson", "text": "

@Matt Joras NSS has an API that makes it easy, very easy even, to add a new TLS extension. This cannot be that hard.

", "time": "2022-07-28T19:33:44Z"}, {"author": "Alan Frindell", "text": "

I think as an optional extension it could be ok

", "time": "2022-07-28T19:33:44Z"}, {"author": "Tommy Pauly", "text": "

We can make the bar for new frames lower though

", "time": "2022-07-28T19:33:44Z"}, {"author": "Matt Joras", "text": "

For example, if you are the owner of a proxy implementation, do you really want users of that proxy writing custom frames?

", "time": "2022-07-28T19:33:46Z"}, {"author": "Erik Nygren", "text": "

and having something like this in envoyproxy and standardized does seem useful, even in proprietary context. The \"HAProxy Prefix\" is an example of what happens when this happens anyways but outside of standards.

", "time": "2022-07-28T19:33:55Z"}, {"author": "Martin Thomson", "text": "

@Matt Joras I don't see why not. Within bounds.

", "time": "2022-07-28T19:34:06Z"}, {"author": "Martin Thomson", "text": "

Alan Frindell said:


I think as an optional extension it could be ok


Your optional extension is something everyone else has to deal with.

", "time": "2022-07-28T19:34:42Z"}, {"author": "Jonathan Hoyland", "text": "

@MeetEcho: Adjourned

", "time": "2022-07-28T19:34:55Z"}]