**Session Date/Time:** 30 Sep 2026 14:00

[00:00:05] **Barry Leiba**: Okay. We're at the top of the hour, and we have a good number of people on. So let's go ahead and get started. Welcome to the September thirtieth CBOR interim meeting. We have a pretty simple agenda, and I hope the meeting will be relatively short. But let's see what we have to talk about. Carsten has just posted yesterday, I think it was, the latest update to EDN literals, and we are ready to discuss where we are with that. Many of the changes that the chairs declared consensus on have been made. There's a few of them are still iffy there. And, Carsten, we'd really like you to apply all the changes that we laid out. Even if there's more discussion to be had, I would rather start from a document that has what the chairs have declared as consensus. But, let's start off. Is there something you wanna say about the changes in the latest version, Carsten?

[00:01:22] **Carsten Bormann**: Sure. So I sent some, email yesterday going through the, I think, 11 items in the list. And I think eight of those items have been addressed, and there are three where we apparently need additional discussion because the discussion items happened in interim meetings or in in other places. So if somebody could share the the web page or preferably the actual email message that is referenced from the pointer in the notes, that would help. Okay. So if you can zoom in slightly. Yeah. The the problem with the mail archive is that this seems to remove the the HTML formatting that I used to make this slightly more easy to read, but I think that's that's not a big problem. Okay. So the the eight changes that were requested, the the number one is is various things that that are are just simple feature removals. So I think those are done. Of course, I might have overlooked something. So that would be the number one. And, of course, it it would be good if people were looking at the diff between twenty seven and twenty eight, whether those are addressed. Number two, I made a little bit of a mistake here initially, but I think I have fixed that because the the actual request here is not to remove the extensibility, but to take the extensibility out of IANA and put in something that talks about standards track documents that might want to use the extensibility. So from my point of view, that is strictly worse than what we had. But, again, I think I have executed what's in that change request. So it it would be useful to to get some input there. Maybe not today. Oh, Joe, it was there. Yeah. Go ahead.

[00:04:26] **Joe Hildebrand**: Yeah. I the intent there was, from my part, I think, was just to remove the extensibility altogether, not only the the IANA part of it. So perhaps that was a miswording on my part or a, you know, transmission transmission through multiple sources sort of thing.

[00:04:52] **Carsten Bormann**: Yeah. Can can which which email is the one that I should be using here?

[00:05:00] **Joe Hildebrand**: Well, I mean, Paul's was the the canonic one, the most recent, but it's possible that he summarized my email without being adequate. I don't know. I'll go back and look and see what I said, but we could let's discuss that on the list and and and come to a conclusion about it. That was my intent, though.

[00:05:25] **Carsten Bormann**: Yeah. So the the problem is that the list that can pull around only has subject lines, and

[00:05:30] **Joe Hildebrand**: so I understand. Yeah.

[00:05:31] **Carsten Bormann**: Yeah. I don't necessarily I'm not necessarily sure I hit the right one of those.

[00:05:39] **Barry Leiba**: And so the Joe, the let's discuss it on the list. Yes. Let's do that if we can't resolve it here. But the purpose of this call is to bring out these things and discuss them. So if if we can have that discussion now, it would be good. If we aren't prepared for that, then fine. We'll take it to the list.

[00:05:57] **Joe Hildebrand**: Well, let's first I think Vadim is on the call. I think he he agreed with me about removing that extensibility. Maybe he could speak up and see if he agreed, if he remembers what we talked about.

[00:06:14] **Carsten Bormann**: So I think I used a change request from Rohan when I

[00:06:19] **Barry Leiba**: did this. Ira is in the queue. Let's let's see what he has to say.

[00:06:22] **Carsten Bormann**: Okay. Yeah. Sorry.

[00:06:24] **Ira McDonald**: I just wanted to ask, Joe, why would you wanna remove extensibility even by future standards track documents? That seems hard to justify.

[00:06:39] **Joe Hildebrand**: I don't think that there's a good use case for it, and having an extensibility point in the tooling is much more difficult than not having an extensibility point.

[00:06:51] **Ira McDonald**: I don't see it as much more difficult.

[00:06:54] **Joe Hildebrand**: I think

[00:06:55] **Ira McDonald**: this sort of, like, okay. We know everything, and we'll never have to fix this, like, in a second edition. And So I I don't get that.

[00:07:07] **Joe Hildebrand**: I think that if we do wanna fix it if we do wanna add new things with the standards action, then it's just adding a new thing into the list. And so you you there's a new rev of the tool. It supports the new RFC. Away we go. But I don't have to have an explicit extensibility point. Whereas if there's certainly, if there's an IANA, registry, my tooling really needs to be able to say, oh, and here's how you write a plug in to enable some future thing that, you know, nobody's ever heard of before.

[00:07:39] **Ira McDonald**: Yeah. Agreed. Carsten, do you have an you said you think it's a know, less less productive than having the IANA registry. Though I understand Joe's point about IANA registries from IEEE printer working group and elsewhere. These things get hidden too often.

[00:08:05] **Carsten Bormann**: Yeah. So the the the first observation is that, of course, the standard strict document can always change this. So not having any extensibility here is is essentially a statement of intent as of 2026, and we don't know how that will survive the next few decades. So that's why I think, generally, when we have a list where we already are making a change right now by by using the I specification. It it's it's an assumption that we will want to extend that later. But I don't want to do this now. So the question really is how does the grammar look like? And and we are looking at the grammar right now in in the bottom third of the screen. And this makes it explicit that we would expect any future extensions to use star word care as as the structure of the additional characters in the encoding indicator. So this is something that that standard strict update can can change, of course, But it's also reasonable assumption so people can structure their implementations to to actually get and ignore those encoding indicators.

[00:09:52] **Joe Hildebrand**: I mean sorry. Ignore? There'd probably be errors.

[00:09:59] **Carsten Bormann**: Well, encoding indicators can can always be ignored.

[00:10:06] **Joe Hildebrand**: I don't I don't understand that. If I don't implement it

[00:10:11] **Carsten Bormann**: Then they have no effect.

[00:10:16] **Joe Hildebrand**: I disagree with that, but we have an ongoing disagreement on accepting bad inputs, I think.

[00:10:35] **Carsten Bormann**: Yeah. Okay. That's an interesting observation. So the the the grammar that that is proposed by Rohan, I have rearranged this slightly, but it it's still the same content. That makes sure that you actually can pause encoding indicators and ignore them even if it's not one of the six encoding indicators that are defined by by this version of of the RFC. And I think that's a good thing. Okay. Maybe we can take it to the list from there. I think we have identified where we have different views. Okay. Has an example in the chat that is not about encoding indicators. So I'm I'm not sure how much that example helps.

[00:11:49] **Michael Richardson**: Just as a point of reference, for as long as I can tell, encoding indicators have always been there with the statement that if you if you don't do them, just ignore them.

[00:12:00] **Carsten Bormann**: So That's what definitely was the intention. Yes.

[00:12:03] **Joe Hildebrand**: I think if you don't do them at all, it's fine to ignore them. But if you are doing them, you find when you do don't process, that's gotta be an error. Well, I'm gonna let me put it this way. My software is gonna throw an error at that point. It's because there's no good way to do warnings. So I'm gonna throw an error, and you guys can decide whatever the text says in the document, but I'm gonna throw an error.

[00:12:22] **Carsten Bormann**: Yep. Yeah. I think the the observation if if if if somebody defines a new encoding indicator in a standard straight document, then then implementations using the ABNF that I briefly had in in the document. You can look at the GitHub to see that. Means the implementation would error out even if it completely ignores encoding indicators. And what Rohan has provided here and which which I ultimately copied would not error out. Okay. I think that was a useful thought and useful discussion. Should we go to the next one?

[00:13:22] **Barry Leiba**: Yes.

[00:13:28] **Carsten Bormann**: I'm not sure of the list again. Ah, the sub point was removing CI. So this is an obvious document shuffling thing that has been done on this side, and and now a document needs to be set up on the side, but that's unrelated to what we have to do here. So that should be fine. And then we had the discussion about the non JSON decimal number forms. So what the discussion on the list doesn't really reflect is that we had a pretty extensive discussion about usability, and we we said we don't necessarily want to limit ourselves to just the the JSON forms of numbers. So that that came up first when we had octal, hexadecimal, and and binary number forms, and and then we looked at insignificant zeros and so on. And the the text that Rohan has provided here says, well, these number forms add no value, which I think is not necessarily a defensible position. And after some discussion, Rohan finally came out with an actual technical reason, which is that if you copy paste data from a c language environment, you might have actual numbers in there, which are indicated by a leading zero, followed by by additional digits. And these would be misunderstood by what what we had before I implemented that change request. So we know an actual technical reason for a change. We we probably still differ in in our assessment of whether this is reason to restrict the number format, but given that we have our decision mechanism here, this is the right thing to do. Now Rohan approved the the the request that that which this initially turned up in, but he also said we should remove the plus sign, and I don't know why. So it would be good to to understand what the other people think we should be removing the plus sign. Just hop right in. Leading plus is not valid in JSON. This This is an extension to JSON.

[00:16:45] **Joe Hildebrand**: Sorry. I was yeah. Then I think that was the reasoning.

[00:16:53] **Carsten Bormann**: Ah, so you seem to have the intention to to limit us to whatever we have in JSON even if there is no reason for that?

[00:17:11] **Joe Hildebrand**: Rohan's here now, so he can probably speak up for himself.

[00:17:16] **Carsten Bormann**: Yes. Can you speak?

[00:17:34] **Michael Richardson**: So we do have a process, but the process also includes the request being for having technical reasons. And the discussion found so far that there was one technical reason and a lot of I'd rather have it this way. I'd rather have it that way. So the idea here is to understand whether there's also a technical reason here. It's just for flexing.

[00:18:19] **Barry Leiba**: It looks like Rohan's having audio problems. So so Rohan says there's a complexity issue, and Vadim says leading plus is harmless.

[00:18:36] **Carsten Bormann**: Yeah. What is the harm of allowing leading plus? That was the actually, the question. If you scroll down to to the footnote with the the star, we can see that that