[{"author": "Francesca Palombini", "text": "

Christian I share your timezone pain :) Nice to see some familiar faces!

", "time": "2023-03-27T00:30:23Z"}, {"author": "Sean Turner", "text": "

Nice big room here!

", "time": "2023-03-27T00:32:43Z"}, {"author": "Christopher Allen", "text": "

Good morning (at least for those of you in Japan)! A beautiful sunny late-afternoon here in California, a calm before our next storm.

", "time": "2023-03-27T00:33:27Z"}, {"author": "Christopher Allen", "text": "

I'm not hearing audio, but am seeing slides \u2014\u00a0has the meeting started?

", "time": "2023-03-27T00:34:22Z"}, {"author": "Jonathan Lennox", "text": "

Yes, I'm hearing audio

", "time": "2023-03-27T00:34:32Z"}, {"author": "Francesca Palombini", "text": "

yes it has, Christopher

", "time": "2023-03-27T00:34:36Z"}, {"author": "Francesca Palombini", "text": "

Thank you Kirsty!!

", "time": "2023-03-27T00:36:29Z"}, {"author": "Francesca Palombini", "text": "

and welcome Jim :)

", "time": "2023-03-27T00:36:47Z"}, {"author": "Murray Kucherawy", "text": "

This coffee clearly isn't working.

", "time": "2023-03-27T00:37:43Z"}, {"author": "Christian Ams\u00fcss", "text": "

Did you have enough of it?

", "time": "2023-03-27T00:37:59Z"}, {"author": "Murray Kucherawy", "text": "

Clearly not.

", "time": "2023-03-27T00:38:05Z"}, {"author": "Michael Richardson", "text": "

Hmm. RFC9277.

", "time": "2023-03-27T00:38:31Z"}, {"author": "Christian Ams\u00fcss", "text": "

Apparently you can add another tag in front of it to announce it's CBOR. Then you just need another character in front to say that it's multiformat...

", "time": "2023-03-27T00:40:12Z"}, {"author": "Murray Kucherawy", "text": "

Does that example string decode into anything?

", "time": "2023-03-27T00:40:17Z"}, {"author": "Christopher Allen", "text": "

I lost audio from Manu. It was working 1m ago. Anyone else?

", "time": "2023-03-27T00:40:59Z"}, {"author": "Richard Barnes", "text": "

working for me

", "time": "2023-03-27T00:41:04Z"}, {"author": "Richard Barnes", "text": "

@Murray - it decodes to \"hello world\" according to Man

", "time": "2023-03-27T00:41:17Z"}, {"author": "Richard Barnes", "text": "

Manu

", "time": "2023-03-27T00:41:19Z"}, {"author": "Murray Kucherawy", "text": "

Yeah I just tried it and got nothing.

", "time": "2023-03-27T00:41:36Z"}, {"author": "Murray Kucherawy", "text": "

Must be the decoder I'm using.

", "time": "2023-03-27T00:42:07Z"}, {"author": "Andrew Campling", "text": "

The closed captioning may be helpful for anyone with audio tech challenges

", "time": "2023-03-27T00:42:21Z"}, {"author": "Michael Richardson", "text": "

AD sponsored RFC, seems like it has to be STD in order to create a registry.

", "time": "2023-03-27T00:42:27Z"}, {"author": "Richard Barnes", "text": "

my impression is that these multiX things are usually pretty domain-specific, wonder whether there's a need for a global thing

", "time": "2023-03-27T00:42:36Z"}, {"author": "Murray Kucherawy", "text": "

@mic what Richard said

", "time": "2023-03-27T00:42:52Z"}, {"author": "Pete Resnick", "text": "

Informational can create a registry, can't they?

", "time": "2023-03-27T00:42:52Z"}, {"author": "Jonathan Rosenberg", "text": "

The syntax here for multi base overlaps with strings not encoded in multi format. I\u2019m curious why there isn\u2019t a magic cookie in front to allow differentiation?

", "time": "2023-03-27T00:42:57Z"}, {"author": "John Klensin", "text": "

Referring to my email of a few hours ago, if there is nothing to do other than publish, why not just set up an IANA registry for the codes and dispatch to the ISE?

", "time": "2023-03-27T00:43:02Z"}, {"author": "Christopher Allen", "text": "

I had to switch browsers.

", "time": "2023-03-27T00:43:27Z"}, {"author": "Pete Resnick", "text": "

@John Klensin Exactly.

", "time": "2023-03-27T00:43:34Z"}, {"author": "Michael Richardson", "text": "

Info can't create a registry that requires the higher levels of specification as consideratrions.

", "time": "2023-03-27T00:43:48Z"}, {"author": "Murray Kucherawy", "text": "

@john What creates the registry? IESG action?

", "time": "2023-03-27T00:43:54Z"}, {"author": "Michael Richardson", "text": "

(OPSAWG, PCAP went through this)

", "time": "2023-03-27T00:43:56Z"}, {"author": "Murray Kucherawy", "text": "

@michael: Does 8126 say that? I'm looking.

", "time": "2023-03-27T00:44:07Z"}, {"author": "John Klensin", "text": "

@Pete: yes. @Jonathan: that is part of what bothered me. Also, having a single-character introducer is looking for \"running out of space\" trouble. I

", "time": "2023-03-27T00:44:25Z"}, {"author": "Michael Richardson", "text": "

I'm certain that ISE can't create registries that require IETF specification.

", "time": "2023-03-27T00:44:36Z"}, {"author": "John Klensin", "text": "

@Murray: yes, I assume IESG would need to sign off.

", "time": "2023-03-27T00:44:42Z"}, {"author": "Christopher Allen", "text": "

I would also love to have at least a list of hashes and keys as registered CBOR tags. We use some that are not registered with IANA in our prototypes.

", "time": "2023-03-27T00:45:02Z"}, {"author": "Pete Resnick", "text": "

@Michael Richardson Why do you think IETF Specs would be involved here?

", "time": "2023-03-27T00:45:03Z"}, {"author": "Sean Turner", "text": "

@Richard Barnes would you like me to say that at the mic? Or are you going to get in the queue?

", "time": "2023-03-27T00:45:07Z"}, {"author": "Martin Thomson", "text": "

@John Klensin I am less concerned about running out of space, but more concerned about the answer to the question: why do you need 25 different formats in a standard?

", "time": "2023-03-27T00:45:30Z"}, {"author": "Christian Ams\u00fcss", "text": "

RISCV have gone through that ... once you run out of single chars, you can always do zba, zbb etc

", "time": "2023-03-27T00:45:33Z"}, {"author": "Michael Richardson", "text": "

@Pete, because 1 byte size, and likely actually 52 letters.

", "time": "2023-03-27T00:45:43Z"}, {"author": "Martin Thomson", "text": "

I tend to subscribe to the highlander model of standardization

", "time": "2023-03-27T00:45:53Z"}, {"author": "Jonathan Lennox", "text": "

Is this only at the IETF so it can get an IANA registry?

", "time": "2023-03-27T00:46:28Z"}, {"author": "Michael Richardson", "text": "

@Martin, it's not that on standard needs that many. It's that when doing forensics, it's nice to be able to figure out which standard applies.

", "time": "2023-03-27T00:46:30Z"}, {"author": "Alex Chernyakhovsky", "text": "

It's unclear to me what the benefit of multihash is over prefixes like sha256: that I've seen appearing in places

", "time": "2023-03-27T00:46:31Z"}, {"author": "John Klensin", "text": "

@AD sponsored still requires IETF consensus and agreement that this is the right think to do

", "time": "2023-03-27T00:46:41Z"}, {"author": "Jonathan Hoyland", "text": "

We could have a letter that signifies \"use next byte as header too\"

", "time": "2023-03-27T00:46:42Z"}, {"author": "Kristina Yasuda", "text": "

To clarify, if by \"Microsoft using multiformats\", the product meant was Entra Verified ID, it uses JWK, not multiformats draft.

", "time": "2023-03-27T00:46:49Z"}, {"author": "Stephen Farrell", "text": "

cfrg would be an awful plan for this

", "time": "2023-03-27T00:46:53Z"}, {"author": "Alexey Melnikov", "text": "

CFRG doesn\u2019t look like the right place for this.

", "time": "2023-03-27T00:47:28Z"}, {"author": "Richard Barnes", "text": "

+1 to not-CFRG

", "time": "2023-03-27T00:47:43Z"}, {"author": "Alexey Melnikov", "text": "

ART area seems right

", "time": "2023-03-27T00:47:45Z"}, {"author": "Martin Thomson", "text": "

I get cryptographic agility, but why do you need to build switching here.

", "time": "2023-03-27T00:47:49Z"}, {"author": "Martin Thomson", "text": "

Definitely not CFRG

", "time": "2023-03-27T00:47:53Z"}, {"author": "John Klensin", "text": "

Is there any existing global registry

", "time": "2023-03-27T00:48:03Z"}, {"author": "Richard Barnes", "text": "

I think JCK is about right -- make it a spec-required registry in whatever the easiest way possible is

", "time": "2023-03-27T00:48:05Z"}, {"author": "Daniel Gillmor", "text": "

if we tweak this a little bit, maybe we can turn it into a variant of ASN.1

", "time": "2023-03-27T00:48:31Z"}, {"author": "Jonathan Hoyland", "text": "

Can a string have two different valid interpretations, one more and one less specific?

", "time": "2023-03-27T00:48:46Z"}, {"author": "Francesca Palombini", "text": "

We have some IANA experts here - maybe they can have suggestions?

", "time": "2023-03-27T00:48:54Z"}, {"author": "Stephen Farrell", "text": "

asn.1 with the bitcoin encoding rules?

", "time": "2023-03-27T00:49:00Z"}, {"author": "Francesca Palombini", "text": "

in response to \"the easiest way possible\" @Richard

", "time": "2023-03-27T00:49:24Z"}, {"author": "Francesca Palombini", "text": "

(and indeed I mean IANA process experts)

", "time": "2023-03-27T00:49:52Z"}, {"author": "Sean Turner", "text": "

$ER

", "time": "2023-03-27T00:49:53Z"}, {"author": "Daniel Gillmor", "text": "

i feel like this is begging for https://xkcd.com/927

", "time": "2023-03-27T00:50:06Z"}, {"author": "Murray Kucherawy", "text": "

I'm not seeing the constraing in 8126 that Michael was talking about.

", "time": "2023-03-27T00:50:28Z"}, {"author": "Martin Thomson", "text": "

I want to understand how you achieve interoperability if you allow a multiformat

", "time": "2023-03-27T00:50:43Z"}, {"author": "Jonathan Hoyland", "text": "

Wow time to 927 was even shorter than last IETF :joy:

", "time": "2023-03-27T00:50:45Z"}, {"author": "Martin Thomson", "text": "

Yes, let's not parallelize standardization

", "time": "2023-03-27T00:51:40Z"}, {"author": "Pete Resnick", "text": "

+1 to @John Klensin : if needed, ISE to create an IANA registry.

", "time": "2023-03-27T00:51:48Z"}, {"author": "Carsten Bormann", "text": "

Interoperability preventer specification: Throw in all base formats you can find (but thank you for cataloging), give the illusion of self-description. ISE sounds like a good way to document this.

", "time": "2023-03-27T00:52:24Z"}, {"author": "Kristina Yasuda", "text": "

IPFS CIDs use multiformats, but that is different from \"a company building a product using IPFS\", equating to \"that company using multiformats\".

", "time": "2023-03-27T00:52:56Z"}, {"author": "Jonathan Hoyland", "text": "

CFRG makes the other groups look _fast _. :sweat_smile::stuck_out_tongue_wink:

", "time": "2023-03-27T00:53:25Z"}, {"author": "John Klensin", "text": "

Having to design a \"what we do when we run out of one character indicators\" followed by \"what we do when we run out of two\", etc., just seems like a recipe for kludge propagation.

", "time": "2023-03-27T00:53:31Z"}, {"author": "Richard Barnes", "text": "

i find fluffy's argument for a small WG plausible

", "time": "2023-03-27T00:54:12Z"}, {"author": "Francesca Palombini", "text": "

AD sponsored is not less work (for anybody) or faster to get doc published (from experience)

", "time": "2023-03-27T00:54:18Z"}, {"author": "Alexey Melnikov", "text": "

+1 to Ted & Fluffy

", "time": "2023-03-27T00:55:36Z"}, {"author": "Stephen Farrell", "text": "

how's the captioning doing with ekr? (can't make out the font from here)

", "time": "2023-03-27T00:55:50Z"}, {"author": "John Klensin", "text": "

So, suppose there is a small WG, and it concludes that a multi-character introducer with a delimiter is that right thing to do? what happens with the existing deployment? If the answer is that the WG would not be allowed to do that, then, IMO, back to the ISE and a descriptive document.

", "time": "2023-03-27T00:55:58Z"}, {"author": "Jonathan Hoyland", "text": "

Is there a letter for multiformat? I guarantee someone will want to do this recursively.

", "time": "2023-03-27T00:56:29Z"}, {"author": "Cullen Jennings", "text": "

Pretty sure IETF would not make gratuitous changes

", "time": "2023-03-27T00:56:49Z"}, {"author": "Christian Ams\u00fcss", "text": "

It may not have a letter for multiformat, but it will have a letter for self-described CBOR, and once there is a media type registered, you can go back and forth indefinitely.

", "time": "2023-03-27T00:57:13Z"}, {"author": "Richard Barnes", "text": "

@Cullen - but the IETF LOVES to make gratuitous changes!

", "time": "2023-03-27T00:57:28Z"}, {"author": "Cullen Jennings", "text": "

Pretty sure IETF would not make gratuitous changes

", "time": "2023-03-27T00:57:32Z"}, {"author": "Jonathan Rosenberg", "text": "

If we added a magic cookie that\u2019s a big change. Not gratuitous if needed but still breaking

", "time": "2023-03-27T00:57:53Z"}, {"author": "Cullen Jennings", "text": "

Haha, good point, let me correct myself, The IETF SHOULD NOT make gratuitous changes

", "time": "2023-03-27T00:58:08Z"}, {"author": "Martin Thomson", "text": "

@Cullen Jennings I think that speaks more to an answer of an ISE dispatch

", "time": "2023-03-27T00:58:26Z"}, {"author": "Alex Chernyakhovsky", "text": "

gratuitous changes need not be breaking either, but assuming an IETF WG wouldn't make breaking changes (likely with good reason) is a stretch

", "time": "2023-03-27T00:58:32Z"}, {"author": "John Klensin", "text": "

@cullen: I didn't say anything about gratuitous. I'm just concerned, partially building on Martin's comment, that this could get very complex in hurry (including the need for language tagging, right-to-left isolation, etc. And then one would probably need a more structured introducer, not one letter.

", "time": "2023-03-27T00:58:44Z"}, {"author": "Jonathan Rosenberg", "text": "

Actually you could do it backwards compatible - use an available letter and that format includes the magic cookie - recursive basically

", "time": "2023-03-27T00:58:58Z"}, {"author": "Martin Thomson", "text": "

@John Klensin I think that it is clear that this is for binary data only

", "time": "2023-03-27T00:59:08Z"}, {"author": "Francesca Palombini", "text": "

reminder that dispatch can't dispatch to ISE - we can say not IETF and see if ISE will pick it up (details but...)

", "time": "2023-03-27T00:59:11Z"}, {"author": "Jonathan Lennox", "text": "

I just lost audio, can someone remind me how to reload audio in Meetecho?

", "time": "2023-03-27T00:59:14Z"}, {"author": "Murray Kucherawy", "text": "

I usually just reload the page

", "time": "2023-03-27T00:59:29Z"}, {"author": "John Klensin", "text": "

@martin: \"binary\" like \"hello world\"??

", "time": "2023-03-27T00:59:35Z"}, {"author": "Martin Thomson", "text": "

@John Klensin I think that was an error. I think that the description should have been\" This is an ASCII encoding of the string \"hello world\"\"

", "time": "2023-03-27T01:00:04Z"}, {"author": "John Klensin", "text": "

@Harald +1

", "time": "2023-03-27T01:01:36Z"}, {"author": "Kristina Yasuda", "text": "

W3C has registries now - why can't identifiers be registered there?

", "time": "2023-03-27T01:01:38Z"}, {"author": "Anthony Nadalin", "text": "

This seems way under specified so far as lack of support for ASN.1 and I don't think we should sponsor this at this time.

", "time": "2023-03-27T01:01:50Z"}, {"author": "Kristina Yasuda", "text": "

+1 to the interoperability concern..

", "time": "2023-03-27T01:02:46Z"}, {"author": "Pete Resnick", "text": "

Think TZ database. If there's already a community, let them use IANA and keep IETF out of this .

", "time": "2023-03-27T01:02:50Z"}, {"author": "Mike Bishop", "text": "

If we're discussing changes to the existing spec, are the current stakeholders here and planning to participate? If they're not, do we need to do this?

", "time": "2023-03-27T01:02:54Z"}, {"author": "Harald Alvestrand", "text": "

W3C has tried to deploy registries. It doesn't have long experience with it.

", "time": "2023-03-27T01:03:01Z"}, {"author": "Ted Hardie", "text": "

Eliot is remote, so you need to find him remotely.

", "time": "2023-03-27T01:03:06Z"}, {"author": "Jonathan Rosenberg", "text": "

My opinion after this discussion: if there is no desire for it changing, informational. If so - small wg.

", "time": "2023-03-27T01:03:24Z"}, {"author": "Harald Alvestrand", "text": "

(Apologies for jokes that could be read as disparaging)

", "time": "2023-03-27T01:03:27Z"}, {"author": "Christian Ams\u00fcss", "text": "

If whoever does this goes with a magic, I'm pretty sure we can find a nice magic cookie that happens to be the RFC9277 tag for \"the following thing is a multiformat\".

", "time": "2023-03-27T01:03:32Z"}, {"author": "Spencer Dawkins", "text": "

I'm not going to say this at a mike, but IIRC, AD sponsored now requires IETF Consensus in order to be approved. If @Ted Hardie is correct about the hot topics being registration policies - and this isn't my area of expertise, but that sounds right - AD sponsored would be an ENORMOUS amount of work for the sponsoring AD. (The AD basically acts as a working group chair AND AD for these drafts)

", "time": "2023-03-27T01:04:04Z"}, {"author": "Carsten Bormann", "text": "

Harald said \"Very poorly thought out, but deployed\" -- There are so many things we have learned that have not gone into this.
\nThe crypto alg registry part is interesting, as we always have had \"recommended\" labels etc. on our registries.

", "time": "2023-03-27T01:04:16Z"}, {"author": "Francesca Palombini", "text": "

Spencer agreed, and why I said AD sponsored is not easier or faster (imo)

", "time": "2023-03-27T01:04:53Z"}, {"author": "Eric Rescorla", "text": "

I'm still confused by how the \"this wont require the AD\".

", "time": "2023-03-27T01:04:55Z"}, {"author": "Martin Thomson", "text": "

@Mark Nottingham suggests that we have a need for registry for something like this. I would argue that interoperability is aided more by removing extensibility, at least for the multibase stuff.

", "time": "2023-03-27T01:05:20Z"}, {"author": "Eric Rescorla", "text": "

@Spencer Dawkins I think it really depends how done the document is

", "time": "2023-03-27T01:05:24Z"}, {"author": "Cullen Jennings", "text": "

Question to MNOT - can you point me an example of W3C registry that might be a good model for this ? I was sort of the view that W3C registries did not work well for things that had active entries being added to it.

", "time": "2023-03-27T01:05:42Z"}, {"author": "Francesca Palombini", "text": "

It will require an AD, but there would be more help to drive the work rather than the AD shepherding it all

", "time": "2023-03-27T01:05:42Z"}, {"author": "Murray Kucherawy", "text": "

I feel supporting chartering for a short-lived WG is less work than sponsoring the document directly.

", "time": "2023-03-27T01:05:46Z"}, {"author": "Eric Rescorla", "text": "

Hmm... OK

", "time": "2023-03-27T01:06:04Z"}, {"author": "Harald Alvestrand", "text": "

https://www.w3.org/TR/did-spec-registries/ is a related registry.

", "time": "2023-03-27T01:06:26Z"}, {"author": "Cullen Jennings", "text": "

thanks

", "time": "2023-03-27T01:06:36Z"}, {"author": "Kristina Yasuda", "text": "

There are two discussions going on at the same time - 1) those discussing if this should be in ietf at all. and those discussing 2) where in ietf it should be.

", "time": "2023-03-27T01:06:51Z"}, {"author": "Kristina Yasuda", "text": "

we can't go to 2) without agreeing on 1)

", "time": "2023-03-27T01:07:02Z"}, {"author": "Martin Thomson", "text": "

@Justin Richer points out that allowing for multiple layers of combination only compounds interoperability issues

", "time": "2023-03-27T01:07:16Z"}, {"author": "Harald Alvestrand", "text": "

W3C seems to have adapted the document process and github in order to run their registries.

", "time": "2023-03-27T01:07:28Z"}, {"author": "Spencer Dawkins", "text": "

Eric Rescorla said:

\n
\n

Spencer Dawkins I think it really depends how done the document is

\n
\n

Eric - I agree, with the friendly amendment that it depends on how done people at the IETF THINK the document is. :grinning_face_with_smiling_eyes: But I take your point.

", "time": "2023-03-27T01:07:33Z"}, {"author": "Ted Hardie", "text": "

The IANA MoU with the IETF is here: https://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf for those who might want to dig into that.

", "time": "2023-03-27T01:08:20Z"}, {"author": "Harald Alvestrand", "text": "

I think the question of whether we have IETF efforts that want to use this is still unanswered.

", "time": "2023-03-27T01:08:26Z"}, {"author": "Murray Kucherawy", "text": "

Harald: +1

", "time": "2023-03-27T01:08:42Z"}, {"author": "Carsten Bormann", "text": "

It might be become an \"attractive protocol\" -- have we done a multiformat version of language tags yet?

", "time": "2023-03-27T01:09:15Z"}, {"author": "Kristina Yasuda", "text": "

Justin's observation that engineering input not requested really resonated with me - a separate IANA registry with controllers seems to be what would address the ask/issue the best, if something needs to be done in ietf at all.

", "time": "2023-03-27T01:09:18Z"}, {"author": "John Klensin", "text": "

@Francesca, @Murray, building on the TZ stuff that Pete mentioned, one might think in terms of a really short (assuming the registration model could be sorted out) document to create the registry (presumably AD-sponsored) and then a substantive informational description to the ISE. I can't speak for Eliot, but I have trouble imagining a well-written document describing a deployed and widely used system being turned down.

", "time": "2023-03-27T01:09:31Z"}, {"author": "Pete Resnick", "text": "

@Ted Hardie Anything in there prevent the ISE path? I'm not seeing it.

", "time": "2023-03-27T01:09:52Z"}, {"author": "John Klensin", "text": "

@Carsten: would \"Argggh\" be an appropriate response?

", "time": "2023-03-27T01:10:12Z"}, {"author": "Murray Kucherawy", "text": "

@jck: I think that model could work too.

", "time": "2023-03-27T01:10:34Z"}, {"author": "Murray Kucherawy", "text": "

And I appreciate the creativity around not taking the plain \"AD sponsor the whole thing\" approach.

", "time": "2023-03-27T01:11:09Z"}, {"author": "Daniel Gillmor", "text": "

is this MIME in json?

", "time": "2023-03-27T01:12:06Z"}, {"author": "Jonathan Hoyland", "text": "

Let's hope no one wants support for ergative verbs :joy:

", "time": "2023-03-27T01:12:49Z"}, {"author": "Murray Kucherawy", "text": "

Well, it was JSON for a bit there.

", "time": "2023-03-27T01:13:17Z"}, {"author": "Daniel Gillmor", "text": "

yeah no longer json

", "time": "2023-03-27T01:13:51Z"}, {"author": "Shivan Sahib", "text": "

does it support comments

", "time": "2023-03-27T01:14:08Z"}, {"author": "John Klensin", "text": "

@Murray: for something like this and unless there is willingness and ability to give up change control in practice, a WG or AD-sponsored still means the specification has to get IETF consensus. I think even this brief discussion we just had suggests that would not be straightforward. So, if the requement is really \"registry\" and \"some sort of RFC\".... And that is independent of your predicted overload for the coming months.

", "time": "2023-03-27T01:14:09Z"}, {"author": "Daniel Gillmor", "text": "

@Shivan Sahib maybe comments are just another form of assertion?

", "time": "2023-03-27T01:15:19Z"}, {"author": "Pete Resnick", "text": "

Is this here because CBOR has already said \"no\"?

", "time": "2023-03-27T01:15:46Z"}, {"author": "Carsten Bormann", "text": "

(Clarification: RFC 8949 defines \"deterministic encoding\" for CBOR, Section 4.2. But you need application profiling to be truly deterministic. So, for this domain, they have written up a profile.

", "time": "2023-03-27T01:15:59Z"}, {"author": "Christian Ams\u00fcss", "text": "

CBOR didn't reject this.

", "time": "2023-03-27T01:16:19Z"}, {"author": "Daniel Gillmor", "text": "

but \"this domain\" seems to be \"every possible document\", right? or am i missing the problem statement?

", "time": "2023-03-27T01:16:36Z"}, {"author": "Richard Barnes", "text": "

my impression here is:(1) Dispatch dCBOR to the CBOR WG, if anywhere(2) Envelopes would need a full BoF, giant piece of work

", "time": "2023-03-27T01:16:38Z"}, {"author": "Carsten Bormann", "text": "

@Pete Resnick: No, we have discussed this, and do see some parts that might make a nice \"application profile\" document.

", "time": "2023-03-27T01:16:44Z"}, {"author": "Eric Rescorla", "text": "

Did CBOR accept it?

", "time": "2023-03-27T01:16:47Z"}, {"author": "Murray Kucherawy", "text": "

Is it within CBOR's charter or do we need to tweak it if we go that way?

", "time": "2023-03-27T01:17:10Z"}, {"author": "Carsten Bormann", "text": "

dCBOR sure is in CBOR's charter

", "time": "2023-03-27T01:17:25Z"}, {"author": "Christian Ams\u00fcss", "text": "

There was no request to adopt it; it should be within our charter.

", "time": "2023-03-27T01:17:32Z"}, {"author": "Michael Richardson", "text": "

I would say that CBOR did not say no. But, there is a lack of enthusiasm among some (me)

", "time": "2023-03-27T01:17:39Z"}, {"author": "Murray Kucherawy", "text": "

OK thanks

", "time": "2023-03-27T01:17:42Z"}, {"author": "Pete Resnick", "text": "

Seems like a pretty darn obvious dispatch decision.

", "time": "2023-03-27T01:18:09Z"}, {"author": "Carsten Bormann", "text": "

If you remove everything that already is standardized in RFC 8949, it becomes a sweet and small document.
\nNot sure who will do that.

", "time": "2023-03-27T01:18:14Z"}, {"author": "Murray Kucherawy", "text": "

\"CBOR-sponsored\"

", "time": "2023-03-27T01:18:42Z"}, {"author": "Daniel Gillmor", "text": "

@Pete Resnick how would you dispatch the Envelope stuff? agreed that dCBOR seems like it gets dispatched to CBOR.

", "time": "2023-03-27T01:18:48Z"}, {"author": "Eric Rescorla", "text": "

I am pretty worried about the envelope stuff without an IETF consumer

", "time": "2023-03-27T01:19:32Z"}, {"author": "Eric Rescorla", "text": "

We're not a protocol design house

", "time": "2023-03-27T01:19:40Z"}, {"author": "Murray Kucherawy", "text": "

+1 to @ekr

", "time": "2023-03-27T01:19:49Z"}, {"author": "Richard Barnes", "text": "

ditto @ekr

", "time": "2023-03-27T01:19:50Z"}, {"author": "Richard Barnes", "text": "

as i said above, Envelope would need a full BoF

", "time": "2023-03-27T01:20:04Z"}, {"author": "Stephen Farrell", "text": "

envelope stuff seems like a very large bit of work, definitely needing a BoF

", "time": "2023-03-27T01:20:10Z"}, {"author": "John Klensin", "text": "

fwiw, another +1 to @ekr

", "time": "2023-03-27T01:20:15Z"}, {"author": "Pete Resnick", "text": "

@Daniel Gillmor ack. Perhaps that would be separate. But given EKR's comment, perhaps the answer to that is /dev/null.

", "time": "2023-03-27T01:20:19Z"}, {"author": "Eric Rescorla", "text": "

I am planning to say that at the mic

", "time": "2023-03-27T01:20:34Z"}, {"author": "Carsten Bormann", "text": "

A small part of Envelope is being done in SCITT right now

", "time": "2023-03-27T01:20:34Z"}, {"author": "Stephen Farrell", "text": "

can dCBOR represent \u03a0?

", "time": "2023-03-27T01:20:40Z"}, {"author": "Murray Kucherawy", "text": "

They are totally separable, yes?

", "time": "2023-03-27T01:20:40Z"}, {"author": "Eric Rescorla", "text": "

@Murray Kucherawy I think so

", "time": "2023-03-27T01:20:45Z"}, {"author": "Murray Kucherawy", "text": "

dCBOR and envlopes

", "time": "2023-03-27T01:20:45Z"}, {"author": "Murray Kucherawy", "text": "

groovy

", "time": "2023-03-27T01:20:53Z"}, {"author": "Daniel Gillmor", "text": "

@Stephen Farrell maybe as the string \"pi\" ?

", "time": "2023-03-27T01:21:06Z"}, {"author": "Eric Rescorla", "text": "

Anyway, my position is conditional on there being no consumer :)

", "time": "2023-03-27T01:21:08Z"}, {"author": "Jonathan Hoyland", "text": "

Who is the consumer outside the IETF?

", "time": "2023-03-27T01:22:18Z"}, {"author": "Eric Rescorla", "text": "

I don't know if there is

", "time": "2023-03-27T01:23:25Z"}, {"author": "Stephen Farrell", "text": "

I hope a thing that's better than x.509 would be simpler than x.509 and not way more complex (which this envelope thing seems like it would be)

", "time": "2023-03-27T01:23:40Z"}, {"author": "Richard Barnes", "text": "

cf https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-02.html

", "time": "2023-03-27T01:23:50Z"}, {"author": "Martin Thomson", "text": "

Are we sure that the elision design here really provides $property? Privacy was mentioned, but I am not sure that replacing content with a hash provides that.

", "time": "2023-03-27T01:23:55Z"}, {"author": "Jonathan Hoyland", "text": "

Especially not if it's deterministic

", "time": "2023-03-27T01:24:23Z"}, {"author": "Carsten Bormann", "text": "

@Stephen Farrell : https://cbor.me/?diag=%22\u03a0%22

", "time": "2023-03-27T01:24:54Z"}, {"author": "Shivan Sahib", "text": "

depends on the content space, no?

", "time": "2023-03-27T01:25:17Z"}, {"author": "Benjamin Schwartz", "text": "

C2PA (https://c2pa.org/) also has a format defined for partially-elidable signed objects

", "time": "2023-03-27T01:25:49Z"}, {"author": "Stephen Farrell", "text": "

@Carsten Bormann thanks what about \u03a0/2? :-)

", "time": "2023-03-27T01:27:15Z"}, {"author": "Andrew Campling", "text": "

Kirsty has asked those in queue to speak quickly \u2026. Next up Ekr! :-)

", "time": "2023-03-27T01:27:56Z"}, {"author": "Rohan Mahy", "text": "

I think the envelope draft needs a requirements and use cases section. If they do that, we might find some folks that could be interested in a BoF. Basically, if the envelope is explained better we might find a consumer.

", "time": "2023-03-27T01:28:49Z"}, {"author": "Eric Rescorla", "text": "

This is just nonresponsive

", "time": "2023-03-27T01:29:47Z"}, {"author": "Murray Kucherawy", "text": "

My meetecho client just completely restarted itself. Anyone else?

", "time": "2023-03-27T01:29:54Z"}, {"author": "Bron Gondwana", "text": "

@Murray mine hasn't restarted

", "time": "2023-03-27T01:30:14Z"}, {"author": "Murray Kucherawy", "text": "

OK must be me, thanks

", "time": "2023-03-27T01:30:21Z"}, {"author": "Eric Rescorla", "text": "

What you need to do is what I said you needed to do: go talk to some existing IETF WGs who want this technology

", "time": "2023-03-27T01:30:21Z"}, {"author": "Bron Gondwana", "text": "

I'm in the full client

", "time": "2023-03-27T01:30:23Z"}, {"author": "Richard Barnes", "text": "

@Murray - Nope, my client has bee nrunning continuously

", "time": "2023-03-27T01:30:46Z"}, {"author": "Wolf McNally", "text": "

Thank you!

", "time": "2023-03-27T01:30:57Z"}, {"author": "Murray Kucherawy", "text": "

Slides are visible.

", "time": "2023-03-27T01:31:24Z"}, {"author": "Robert Sparks", "text": "

@murray - wifi in this room is doing \"fun\" things. NOC is working on it.

", "time": "2023-03-27T01:31:30Z"}, {"author": "Murray Kucherawy", "text": "

@Robert: roger, thanks

", "time": "2023-03-27T01:31:39Z"}, {"author": "Lucas Pardue", "text": "

Is this a variant of what's being discussed in the MoQ WG?

", "time": "2023-03-27T01:34:11Z"}, {"author": "Jonathan Rosenberg", "text": "

How is this different than moq?

", "time": "2023-03-27T01:34:18Z"}, {"author": "Richard Barnes", "text": "

maybe they don't want to use QUIC?

", "time": "2023-03-27T01:34:43Z"}, {"author": "Benjamin Schwartz", "text": "

Sounds a lot like WISH to me

", "time": "2023-03-27T01:34:48Z"}, {"author": "Alan Frindell", "text": "

The draft mostly specifies the signaling messages rather than how to move the bits I think

", "time": "2023-03-27T01:35:13Z"}, {"author": "Eric Rescorla", "text": "

Does this use blockchain?

", "time": "2023-03-27T01:35:36Z"}, {"author": "Jonathan Hoyland", "text": "

I don't think any blockchain application would be called \"low-latency\"

", "time": "2023-03-27T01:36:18Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Hoyland the statement is, as always, relative

", "time": "2023-03-27T01:36:36Z"}, {"author": "Benjamin Schwartz", "text": "

I think the control functionality is basically an RPC API for a live TV production suite

", "time": "2023-03-27T01:36:37Z"}, {"author": "Benjamin Schwartz", "text": "

The rest of it is (or should be) standard WebRTC, WISH, MoQ, etc.

", "time": "2023-03-27T01:37:02Z"}, {"author": "Lucas Pardue", "text": "

Why not use HTTP for signaling?

", "time": "2023-03-27T01:37:13Z"}, {"author": "Pete Resnick", "text": "

Is the simple dispatch solution \"MOQ\" or \"WISH\"?

", "time": "2023-03-27T01:37:41Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland https://ieeexplore.ieee.org/document/9917546/ is \"data propagation for low latency blockchain systems\"

", "time": "2023-03-27T01:38:09Z"}, {"author": "Jonathan Rosenberg", "text": "

Yes dispatch to moq I think

", "time": "2023-03-27T01:38:22Z"}, {"author": "Benjamin Schwartz", "text": "

@Pete Resnick That's not obvious to me. It seems like this is a much higher layer than either of those.

", "time": "2023-03-27T01:38:37Z"}, {"author": "Murray Kucherawy", "text": "

@Ted or @Alan: is this within your charter?

", "time": "2023-03-27T01:38:44Z"}, {"author": "Alex Chernyakhovsky", "text": "

Jonathan Hoyland said:

\n
\n

I don't think any blockchain application would be called \"low-latency\"

\n
\n

something something \"lightning protocol\"?

", "time": "2023-03-27T01:38:53Z"}, {"author": "Ted Hardie", "text": "

@Murray No

", "time": "2023-03-27T01:38:55Z"}, {"author": "Murray Kucherawy", "text": "

Do you think it should be? :)

", "time": "2023-03-27T01:39:18Z"}, {"author": "Jonathan Rosenberg", "text": "

Yes but it\u2019s close enough to their scope to decide to use or add as a work item or what have you

", "time": "2023-03-27T01:39:19Z"}, {"author": "Ted Hardie", "text": "

Look again at slide one; the author is looking for a single signalling messaging format across many different transmission protocols.

", "time": "2023-03-27T01:39:36Z"}, {"author": "Murray Kucherawy", "text": "

hmm

", "time": "2023-03-27T01:39:53Z"}, {"author": "Richard Barnes", "text": "

@Ted so it has nothing to do with latency?

", "time": "2023-03-27T01:40:13Z"}, {"author": "Ted Hardie", "text": "

I think this is based on a gap analysis that presumes people want a single method, without regards to the underlying transmisison system. That does not match my experience.

", "time": "2023-03-27T01:40:41Z"}, {"author": "Benjamin Schwartz", "text": "

It's closest to the \"sector\" of WISH, but definitely outside WISH's current narrow charter.

", "time": "2023-03-27T01:40:43Z"}, {"author": "Pete Resnick", "text": "

@Ted Hardie So the question is who the consumer of this is going to be?

", "time": "2023-03-27T01:41:54Z"}, {"author": "Benjamin Schwartz", "text": "

I'm having trouble figuring out how this would ever be standards-relevant. Maybe if you want to build some kind of complicated live video system with an Off-The-Shelf backend?

", "time": "2023-03-27T01:44:23Z"}, {"author": "Sean Turner", "text": "

Definitely outside of WISH as currently written.

", "time": "2023-03-27T01:45:19Z"}, {"author": "Benjamin Schwartz", "text": "

Usually these backends end up being very highly customized for the application, so I'm not sure this is realistic.

", "time": "2023-03-27T01:45:31Z"}, {"author": "Murray Kucherawy", "text": "

@Alan: More drafts!

", "time": "2023-03-27T01:45:31Z"}, {"author": "Harald Alvestrand", "text": "

It's hard to control media streams without intimate knowledge of the properties of those media streams. So abstraction is hard.

", "time": "2023-03-27T01:45:46Z"}, {"author": "Alan Frindell", "text": "

@murray Is there a record we can go for?

", "time": "2023-03-27T01:45:52Z"}, {"author": "Richard Barnes", "text": "

@Ted i mean, isn't SIP a signaling system that is separate from the delivery architecture?

", "time": "2023-03-27T01:46:02Z"}, {"author": "Lucas Pardue", "text": "

Perhaps I lack imagination but I am struggling to see the value of the abstraction, since its just a few messages types

", "time": "2023-03-27T01:47:12Z"}, {"author": "Benjamin Schwartz", "text": "

I can imagine this as a layer between MoQ/WISH and XMPP, for some kind of standardized Really Big Meeting videochat capability.

", "time": "2023-03-27T01:47:54Z"}, {"author": "Lucas Pardue", "text": "

So transcode signalling needed too?

", "time": "2023-03-27T01:48:26Z"}, {"author": "Benjamin Schwartz", "text": "

In that case, I would want to see the \"bindings\" of these messages into some actual standards-based chat system, and some implementer interest on that end.

", "time": "2023-03-27T01:48:49Z"}, {"author": "Martin Thomson", "text": "

No one mentioned SIPCORE

", "time": "2023-03-27T01:49:12Z"}, {"author": "Benjamin Schwartz", "text": "

Woohoo Opus!

", "time": "2023-03-27T01:49:21Z"}, {"author": "Jonathan Lennox", "text": "

MMUSIC!

", "time": "2023-03-27T01:49:24Z"}, {"author": "Murray Kucherawy", "text": "

Which WG did the original Opus work? Was it called OPUS?

", "time": "2023-03-27T01:49:28Z"}, {"author": "Jonathan Lennox", "text": "

It was called CODEC

", "time": "2023-03-27T01:49:35Z"}, {"author": "Benjamin Schwartz", "text": "

CODEC

", "time": "2023-03-27T01:49:36Z"}, {"author": "Murray Kucherawy", "text": "

thanks

", "time": "2023-03-27T01:49:39Z"}, {"author": "Richard Barnes", "text": "

not our most creative WG naming

", "time": "2023-03-27T01:49:57Z"}, {"author": "Murray Kucherawy", "text": "

I was gonna say

", "time": "2023-03-27T01:50:05Z"}, {"author": "Ted Hardie", "text": "

@Richard I think this more abstract than SIP, by several orders of magnitude. As Harald and Benjamin pointed out, without a mapping, it's not clear what use this abstraction is.

", "time": "2023-03-27T01:50:13Z"}, {"author": "Jonathan Lennox", "text": "

We had enough other worries creating that group

", "time": "2023-03-27T01:50:13Z"}, {"author": "Martin Thomson", "text": "

We should call it COCODEC (child of codec)

", "time": "2023-03-27T01:50:17Z"}, {"author": "Murray Kucherawy", "text": "

So this can be CODECBIS

", "time": "2023-03-27T01:50:18Z"}, {"author": "Jonathan Lennox", "text": "

I like OPUSEXT

", "time": "2023-03-27T01:50:32Z"}, {"author": "Richard Barnes", "text": "

@Martin - no, coCODEC is CODEC with all the arrows reversed

", "time": "2023-03-27T01:50:40Z"}, {"author": "Cullen Jennings", "text": "

For the record, I am very confused on how the chairs reached their conclusion on knowing the consensus of the room on the previous presentation

", "time": "2023-03-27T01:50:40Z"}, {"author": "Jonathan Lennox", "text": "

It's not a bis, it's extensions

", "time": "2023-03-27T01:50:41Z"}, {"author": "Ted Hardie", "text": "

The plural of OPUS is OPERA, if that helps.

", "time": "2023-03-27T01:50:41Z"}, {"author": "Christian Ams\u00fcss", "text": "

COUNDEC (10 + 1 = 11)

", "time": "2023-03-27T01:50:52Z"}, {"author": "Spencer Dawkins", "text": "

Harald Alvestrand said:

\n
\n

It's hard to control media streams without intimate knowledge of the properties of those media streams. So abstraction is hard.

\n
\n

Agreed, and I'd honestly say it's going to be harder in the near future, with higher bitrates, more scalable codecs, more related but seperate media flows, and probably other things I can't think of on a Monday morning in Japan.

", "time": "2023-03-27T01:52:18Z"}, {"author": "Ted Hardie", "text": "

We could riff on bloom county (https://bloomcounty.fandom.com/wiki/Opus) and call the follow-on Milo. I'm sure someone can backronym that.

", "time": "2023-03-27T01:52:25Z"}, {"author": "Michael Richardson", "text": "

could also be dispatched to CELLAR? (with minor recharter)

", "time": "2023-03-27T01:52:29Z"}, {"author": "Pete Resnick", "text": "

@Cullen Jennings I read it as concluding a lack of consensus to dispatch anywhere in particular at this time.

", "time": "2023-03-27T01:52:34Z"}, {"author": "Michael Richardson", "text": "

(but, I haven't read the ID)

", "time": "2023-03-27T01:52:52Z"}, {"author": "Kirsty Paine", "text": "

Hi Cullen, based on zulip and discussion in the room, the consensus was that it would be MOQ if anywhere for an existing WG, but that it's not in scope of the charter and the work spans more than only MOQ. Therefore it makes sense to understand why not MOQ or if it could be included with a change of charter scope, and also where else in the IETF it applies to help with a clearer dispatch.

", "time": "2023-03-27T01:53:01Z"}, {"author": "Murray Kucherawy", "text": "

@mcr: It's short, actually.

", "time": "2023-03-27T01:53:03Z"}, {"author": "Jonathan Hoyland", "text": "

I bet chatgpt is good at backronyms

", "time": "2023-03-27T01:53:09Z"}, {"author": "Jonathan Lennox", "text": "

CELLAR was specifically for lossless codecs for archival purposes, this is a different community

", "time": "2023-03-27T01:53:13Z"}, {"author": "Murray Kucherawy", "text": "

dredd

", "time": "2023-03-27T01:54:11Z"}, {"author": "David Waite", "text": "

My audio cut out for the middle one :innocent:

", "time": "2023-03-27T01:54:16Z"}, {"author": "Richard Barnes", "text": "

https://imgflip.com/i/7fykvj

", "time": "2023-03-27T01:54:40Z"}, {"author": "Murray Kucherawy", "text": "

nice

", "time": "2023-03-27T01:54:52Z"}, {"author": "Murray Kucherawy", "text": "

The draft is surprisingly short.

", "time": "2023-03-27T01:56:09Z"}, {"author": "Murray Kucherawy", "text": "

OK, we have a co-chair.

", "time": "2023-03-27T01:56:42Z"}, {"author": "Richard Barnes", "text": "

@mic clarifying question: Is this OPUS extensions or a new codec?

", "time": "2023-03-27T01:56:43Z"}, {"author": "Spencer Dawkins", "text": "

Jonathan Lennox said:

\n
\n

CELLAR was specifically for lossless codecs for archival purposes, this is a different community

\n
\n

(speaking as @Michael Richardson 's co-chair - that's true, but the question is whether CELLAR to \"wrong enough\" to eliminate it.

", "time": "2023-03-27T01:56:45Z"}, {"author": "Sean Turner", "text": "

+1 to jdr

", "time": "2023-03-27T01:57:03Z"}, {"author": "Richard Barnes", "text": "

@mic withdrawn, never mind, clear from response to JDR's question

", "time": "2023-03-27T01:57:42Z"}, {"author": "Murray Kucherawy", "text": "

What he needs is a CODEC extension.

", "time": "2023-03-27T01:58:47Z"}, {"author": "Martin Thomson", "text": "

@Stephan Wenger can you type the comment/question?

", "time": "2023-03-27T01:58:50Z"}, {"author": "Daniel Gillmor", "text": "

so meta

", "time": "2023-03-27T01:58:59Z"}, {"author": "Pete Resnick", "text": "

Not lossless

", "time": "2023-03-27T01:59:10Z"}, {"author": "Murray Kucherawy", "text": "

aaaand a second co-chair.

", "time": "2023-03-27T02:00:32Z"}, {"author": "Francesca Palombini", "text": "

people who would be willing to participate/put in energy in a possible wg, please manifest yourself in the chat :) that's helpful

", "time": "2023-03-27T02:00:36Z"}, {"author": "Murray Kucherawy", "text": "

^^ that

", "time": "2023-03-27T02:00:49Z"}, {"author": "Stephan Wenger", "text": "

Recommend WG. Can\u2019t take IETF rec text

", "time": "2023-03-27T02:00:56Z"}, {"author": "Stephan Wenger", "text": "

Can\u2019t take IETF rec text to other orgs

", "time": "2023-03-27T02:01:23Z"}, {"author": "Kirsty Paine", "text": "

thank you for your view, it will be added to the notes

", "time": "2023-03-27T02:01:49Z"}, {"author": "Murray Kucherawy", "text": "

\"rec text\"?

", "time": "2023-03-27T02:01:53Z"}, {"author": "Stephan Wenger", "text": "

that\u2019s despite lack of IETF competence

", "time": "2023-03-27T02:02:00Z"}, {"author": "Martin Thomson", "text": "

This is a pretty sensible way to do this. ML codecs exist and can get insanely low bitrates, but it's hard to see the benefit of saving those bits on modern networks, but redundancy is a very good application.

", "time": "2023-03-27T02:02:14Z"}, {"author": "Stephan Wenger", "text": "

rec->rfc

", "time": "2023-03-27T02:02:16Z"}, {"author": "Jonathan Hoyland", "text": "

What is side information? Speech vs music?

", "time": "2023-03-27T02:04:13Z"}, {"author": "Martin Thomson", "text": "

I think that Jean-Marc was talking about using the Opus encoding then post-processing to improve quality. \"Side information\" might just be the original uncompressed audio.

", "time": "2023-03-27T02:05:44Z"}, {"author": "Timothy Terriberry", "text": "

@Jonathan Hoyland Extra details about the features of the audio in each packet, beyond what can be coded with the existing Opus bitstream.

", "time": "2023-03-27T02:06:10Z"}, {"author": "Timothy Terriberry", "text": "

Think something like extending a narrowband Opus packet to wideband, with fewer bits than Opus would need to do that directly.

", "time": "2023-03-27T02:07:23Z"}, {"author": "Benjamin Schwartz", "text": "

... but more bits than a straight ML codec would need

", "time": "2023-03-27T02:08:20Z"}, {"author": "Spencer Dawkins", "text": "

I'm +1 on @Benjamin Schwartz 's mention of the amount of code in the current OPUS spec. I was not involved at the time, but I was told by other people that implementers all started with the code in the specification and modified in isolation, so publishing a revised OPUS spec that people could use was considered to be very difficult.

", "time": "2023-03-27T02:08:21Z"}, {"author": "Richard Barnes", "text": "

ECRIT rides again!

", "time": "2023-03-27T02:11:27Z"}, {"author": "Murray Kucherawy", "text": "

I was just wondering that.

", "time": "2023-03-27T02:11:35Z"}, {"author": "Benjamin Schwartz", "text": "

I'd like some more clarity on why extensions to Opus make sense. In particular, for 1:1 calling (by far the majority use case), a new codec will perform better.

", "time": "2023-03-27T02:11:58Z"}, {"author": "Ian Williams", "text": "

Does IETF normally handle standards that would only apply to a single country? This seems pretty much exclusively for use in the US/Canada/Mexico.

", "time": "2023-03-27T02:12:48Z"}, {"author": "Eric Rescorla", "text": "

Why would this not be useful outside the US?

", "time": "2023-03-27T02:13:09Z"}, {"author": "Ian Williams", "text": "

Even if you were to s/911/112, this still wouldn't be globally applicable.

", "time": "2023-03-27T02:13:10Z"}, {"author": "Richard Barnes", "text": "

@Ian - The ECRIT WG covered emergency services in a way that would apply to multiple countries' services

", "time": "2023-03-27T02:13:13Z"}, {"author": "Deb Cooley", "text": "

In North America?

", "time": "2023-03-27T02:13:15Z"}, {"author": "Richard Barnes", "text": "

I would assume we would do the same thing here

", "time": "2023-03-27T02:13:20Z"}, {"author": "Ted Hardie", "text": "

@Richard ECRIT is still open

", "time": "2023-03-27T02:13:43Z"}, {"author": "Benjamin Schwartz", "text": "

Maybe there's a use case for Opus extensions in multiparty calling under some particular assumptions about asymmetric bandwidth and end-to-end encryption (or not) and the mix of clients that support which modes, but it's not obvious to me.

", "time": "2023-03-27T02:13:47Z"}, {"author": "Ian Williams", "text": "

Deb Cooley said:

\n
\n

In North America?

\n
\n

You're correct, edited. Anywhere in the NANP, I guess.

", "time": "2023-03-27T02:13:48Z"}, {"author": "Alex Chernyakhovsky", "text": "

The hard part here is \"emergency services call\", not the literal number dialed?

", "time": "2023-03-27T02:13:50Z"}, {"author": "Richard Barnes", "text": "

@Ted lol TIL

", "time": "2023-03-27T02:13:55Z"}, {"author": "Jonathan Hoyland", "text": "

This sounds like a way to make SWAT-ing people much easier

", "time": "2023-03-27T02:13:58Z"}, {"author": "Ted Hardie", "text": "

If we are dispatching this to an existing group, they're the right group.

", "time": "2023-03-27T02:14:13Z"}, {"author": "Jonathan Lennox", "text": "

I feel like the \"how do I talk to a hotspot without credentials\" part needs to be at least partly in IEEE 802.11?

", "time": "2023-03-27T02:14:20Z"}, {"author": "Richard Barnes", "text": "

Yeah, if ECRIT is still open, just dispatch there

", "time": "2023-03-27T02:14:31Z"}, {"author": "Jonathan Rosenberg", "text": "

Is this a layer 2 problem here?

", "time": "2023-03-27T02:14:35Z"}, {"author": "Jonathan Lennox", "text": "

Though how the hotspot enforces that the connection is only used for emergency services seems like a very hard problem

", "time": "2023-03-27T02:14:54Z"}, {"author": "Richard Barnes", "text": "

i expect there are problems at several layers here

", "time": "2023-03-27T02:15:15Z"}, {"author": "Jon Peterson", "text": "

What do we need on an endpoint? Some sort of backdoor apparently

", "time": "2023-03-27T02:15:17Z"}, {"author": "Ted Hardie", "text": "

https://datatracker.ietf.org/wg/ecrit/about/ doesn't give a lot of connection to WiFi, but it's clearly the best match.

", "time": "2023-03-27T02:15:19Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Rosenberg I was thinking a much higher layer: This sounds like mostly a regulatory issue, not a protocol issue. But I'm fine passing this off to ECRIT.

", "time": "2023-03-27T02:15:27Z"}, {"author": "Jonathan Rosenberg", "text": "

It only goes to ecrit if this is actually an application protocol

", "time": "2023-03-27T02:16:03Z"}, {"author": "Eric Rescorla", "text": "

You'd just have to pinky promise

", "time": "2023-03-27T02:16:07Z"}, {"author": "Stephen Farrell", "text": "

if the price of a hotspot being able to do this is that everyone's location is exposed to the network, that's a noteworthy cost

", "time": "2023-03-27T02:16:23Z"}, {"author": "Richard Barnes", "text": "

@JDR - i think the application bits go to ECRIT, the lower layer bits go to 802.11

", "time": "2023-03-27T02:16:25Z"}, {"author": "Christian Ams\u00fcss", "text": "

The topic of SWATting is one the operators of these lines will need to address; it's a classical trade-off between security and reliability, and the trade-off is already taken (IMO justifiedly so) in the direction of reliability.

", "time": "2023-03-27T02:16:39Z"}, {"author": "Jonathan Rosenberg", "text": "

it\u2019s not clear what new application work is requested here beyond existing standards

", "time": "2023-03-27T02:17:10Z"}, {"author": "Jon Peterson", "text": "

every device mandated to have a backdoor, erm\u2026 not an ietf shaped problem?

", "time": "2023-03-27T02:17:20Z"}, {"author": "Christian Ams\u00fcss", "text": "

Best we can do there is to provide guidance on propagating information about the accountability of the caller to the emergency services.

", "time": "2023-03-27T02:17:31Z"}, {"author": "Jim Fenton", "text": "

Did I hear him say something about having the FCC require a way to identify the endpoint? Sounds like a privacy issue.

", "time": "2023-03-27T02:17:36Z"}, {"author": "Daniel Gillmor", "text": "

the other cost is requiring federated credentials for network access, no? it's not just location, it looks like it's location plus identity

", "time": "2023-03-27T02:17:40Z"}, {"author": "Jonathan Hoyland", "text": "

With today's systems your call is bound to the callers device. Things would bind the call to a (supposedly) nearby device.

", "time": "2023-03-27T02:17:42Z"}, {"author": "Richard Barnes", "text": "

@Hoyland - If I understand the proposal correctly, a SWATting attacker would need a physically proximate accomplice, which seems like a fair degree of mitigation

", "time": "2023-03-27T02:18:53Z"}, {"author": "Jonathan Hoyland", "text": "

With a directional antenna you can connect to a WiFi network over hundreds of meters

", "time": "2023-03-27T02:19:26Z"}, {"author": "Jonathan Hoyland", "text": "

In a dense city that could scope in thousands of suspects

", "time": "2023-03-27T02:20:01Z"}, {"author": "Martin Thomson", "text": "

@Richard Barnes I'm fairly sure that the location piece is not entirely solved, though our old friend \"location by reference\" might help

", "time": "2023-03-27T02:20:02Z"}, {"author": "Daniel Gillmor", "text": "

@Richard Barnes they need a device close to the AP (or in range via a directional antenna, per Hoyland), doesn't need to be a human accomplice

", "time": "2023-03-27T02:20:06Z"}, {"author": "Benjamin Schwartz", "text": "

This looks like a 3-party security protocol to me. For example, it's not easy for the client to prove to the hotspot that it's actually talking to an e911 server. I suspect I could use this to freeload arbitrary access via the hotspot and a specialized proxy server.

", "time": "2023-03-27T02:20:28Z"}, {"author": "Richard Barnes", "text": "

@dkg correct

", "time": "2023-03-27T02:20:30Z"}, {"author": "Martin Thomson", "text": "

Tunnels > repeaters

", "time": "2023-03-27T02:20:34Z"}, {"author": "Jonathan Hoyland", "text": "

Also the other issue is priority

", "time": "2023-03-27T02:21:00Z"}, {"author": "Murray Kucherawy", "text": "

Thanks for the reminder about ECRIT. I need to nudge them for other work as well.

", "time": "2023-03-27T02:21:06Z"}, {"author": "Mike Bishop", "text": "

This sounds like a WFA problem for the most part, no?

", "time": "2023-03-27T02:21:21Z"}, {"author": "Jonathan Hoyland", "text": "

If we require a network to prioritise this traffic you have an unblockable DOS vector

", "time": "2023-03-27T02:21:33Z"}, {"author": "Pete Resnick", "text": "

+1 @Ted Hardie

", "time": "2023-03-27T02:21:34Z"}, {"author": "Martin Thomson", "text": "

@Mike Bishop totally not

", "time": "2023-03-27T02:21:35Z"}, {"author": "Richard Barnes", "text": "

if we have location privacy issues, we can always reboot GEOPRIV :upside_down_face:

", "time": "2023-03-27T02:21:45Z"}, {"author": "Harald Alvestrand", "text": "

Tim, one question I did not ask before ... will the use of padding bits risk conflicting with existing use of padding (those who use padding for ... padding)?

", "time": "2023-03-27T02:21:49Z"}, {"author": "Martin Thomson", "text": "

@Timothy Terriberry see @Harald Alvestrand's question

", "time": "2023-03-27T02:22:22Z"}, {"author": "Timothy Terriberry", "text": "

@Harald Alvestrand RFC 6716 currently says the encoder MUST store zeroes in the padding.

", "time": "2023-03-27T02:22:23Z"}, {"author": "Daniel Gillmor", "text": "

@Benjamin Schwartz seems like difficult proofs in the other direction too -- if i'm asking the network to connect me to their preferred local emergency services provider, how do i know that they've made a reasonable choice?

", "time": "2023-03-27T02:22:26Z"}, {"author": "Spencer Dawkins", "text": "

Ted Hardie said:

\n
\n

If we are dispatching this to an existing group, they're the right group.

\n
\n

@Ted Hardie , I was looking at ECRIT Just Yesterday (huddled with the vCon proponents), and was stunned to see that it was still open. Without doing archeology, it looks like it was left open until all the documents were published, and they have one document in MISSREF for just under a year.

\n

Mechanically, it's easier to DISPATCH to ECRIT, but there's likely charter work (and even asking the three co-chairs if they're willing to continue to serve for new work - according to the datatracker, they've had one meeting in the past four years, and https://datatracker.ietf.org/doc/minutes-interim-2022-ecrit-01-202208180730/ only names one co-chair).

", "time": "2023-03-27T02:22:57Z"}, {"author": "Martin Thomson", "text": "

@Timothy Terriberry isn't that a problem? or does it also say that the receiver needs to ignore the padding?

", "time": "2023-03-27T02:23:04Z"}, {"author": "Martin Thomson", "text": "

Did you not build in an extensibility mechanism for Opus?

", "time": "2023-03-27T02:23:16Z"}, {"author": "Benjamin Schwartz", "text": "

dkg: Also that seems like something that could easily be misconfigured on a double-digit percentage of access points, resulting in serious degradation in 911 access.

", "time": "2023-03-27T02:23:19Z"}, {"author": "Robert Sparks", "text": "

@tim - you didn't hear harald's question

", "time": "2023-03-27T02:23:29Z"}, {"author": "Timothy Terriberry", "text": "

@Martin Thomson It also says the decoder MUST ignore the contents, correct.

", "time": "2023-03-27T02:23:34Z"}, {"author": "Murray Kucherawy", "text": "

@spencer: I just noticed that too. The MISSREF document had expired, so the datatracker marked it \"DEAD\". I just ressurrected it.

", "time": "2023-03-27T02:23:34Z"}, {"author": "Daniel Gillmor", "text": "

@Benjamin Schwartz right -- then your device also needs to know how to prioritize between multiple alternate emergency call channels

", "time": "2023-03-27T02:23:55Z"}, {"author": "Jean-Marc Valin", "text": "

@Martin Thomson It's almost like someone had extensibility in mind when writing RFC6716 ;-)

", "time": "2023-03-27T02:24:11Z"}, {"author": "Ted Hardie", "text": "

@Spencer I really just mean that they have the right folks to talk to--Brian, Randy, and crew are still working on new docs and are still connected to NENA. If there is new work here, it would require a recharter (or a new WG), but they're the right next stop, in my opinion.

", "time": "2023-03-27T02:24:18Z"}, {"author": "Alissa Cooper", "text": "

the ecrit/geopriv participant overlap was significant anyway, so might as well charter-tweak ecrit if this needs a WG to land

", "time": "2023-03-27T02:24:34Z"}, {"author": "Robert Sparks", "text": "

I think harald's asking why padding exists now, and are there uses of it that would be disrupted (if the size of the padding changes for instance) with this new use.

", "time": "2023-03-27T02:24:52Z"}, {"author": "Jean-Marc Valin", "text": "

@Harald Alvestrand Since the existing padding is zeros, we made sure that extension ID zero is \"padding\" so as to not cause confusion

", "time": "2023-03-27T02:25:28Z"}, {"author": "Martin Thomson", "text": "

@Jean-Marc Valin https://datatracker.ietf.org/doc/html/rfc9170#section-2-6 : The set of interoperable features in a protocol is often the subset of its features that have some value to those implementing and deploying the protocol. It is not always the case that future extensibility is in that set.

", "time": "2023-03-27T02:25:56Z"}, {"author": "Harald Alvestrand", "text": "

@Jean-Marc Valin thanks. That alleviates my worry.

", "time": "2023-03-27T02:26:06Z"}, {"author": "Francesca Palombini", "text": "

I'll take 2 min in the end chairs please

", "time": "2023-03-27T02:26:13Z"}, {"author": "Jonathan Lennox", "text": "

I think the fact that almost everybody is using something derived from the opus.org code means that hopefully no one has started checking the value of the padding.

", "time": "2023-03-27T02:26:44Z"}, {"author": "Martin Thomson", "text": "

Is that JSON-LD?

", "time": "2023-03-27T02:27:27Z"}, {"author": "Jonathan Lennox", "text": "

Sorry, opus-codec.org

", "time": "2023-03-27T02:27:38Z"}, {"author": "Michael Richardson", "text": "

I use tripit.com, and I have tried repeatedly to get them to do something like this, but they were just clueless about why a standard would help them...

", "time": "2023-03-27T02:27:46Z"}, {"author": "Spencer Dawkins", "text": "

Ted Hardie said:

\n
\n

@Spencer I really just mean that they have the right folks to talk to--Brian, Randy, and crew are still working on new docs and are still connected to NENA. If there is new work here, it would require a recharter (or a new WG), but they're the right next stop, in my opinion.

\n
\n

Thanks for the update - I didn't know that The Usual Suspects are also working on other documents, and that definitely sounds like rechartering ECRIT is the right thing to do.

", "time": "2023-03-27T02:27:58Z"}, {"author": "Pete Resnick", "text": "

We can hear you.

", "time": "2023-03-27T02:28:06Z"}, {"author": "Pete Resnick", "text": "

Lost your audio

", "time": "2023-03-27T02:28:30Z"}, {"author": "Jonathan Rosenberg", "text": "

Frankly gpt3 and similar models can probably parse the email and do entity extraction without needing to add structured data\u2026

", "time": "2023-03-27T02:28:33Z"}, {"author": "Jim Fenton", "text": "

...and then probably do the wrong thing?

", "time": "2023-03-27T02:28:59Z"}, {"author": "Benjamin Schwartz", "text": "

A SML standard sounds good, but I don't think the IETF should be in the business of defining how to represent airline flights or package deliveries or whatever.

", "time": "2023-03-27T02:29:24Z"}, {"author": "Spencer Dawkins", "text": "

@Francesca Palombini - hold up the small human! (if awake)

", "time": "2023-03-27T02:29:25Z"}, {"author": "Murray Kucherawy", "text": "

haha

", "time": "2023-03-27T02:29:33Z"}, {"author": "Francesca Palombini", "text": "

not awake, sorry!

", "time": "2023-03-27T02:29:36Z"}, {"author": "Spencer Dawkins", "text": "

Francesca Palombini said:

\n
\n

not awake, sorry!

\n
\n

Plan for a San Francisco unveiling!

", "time": "2023-03-27T02:30:15Z"}, {"author": "Francesca Palombini", "text": "

But I am sure you will catch him in another meeting :D

", "time": "2023-03-27T02:30:16Z"}, {"author": "John Klensin", "text": "

@Francesca: consider bringing him to the plenary

", "time": "2023-03-27T02:30:23Z"}]