Session Date/Time: 19 Aug 2026 14:00
[00:00:09] Christian Amsüss: Okay. We're at the top of the hour. And while the two people from whom I hoped to to whom I'd have the most concrete questions are already here, let's give it a moment for a few more people to arrive.
[00:00:34] Carsten Bormann: Can you show the list again or maybe provide a link?
[00:00:40] Christian Amsüss: The link is also in the minutes. But, yeah, I'm switching already to the list. Both the links to the list, and to the the general minutes of today, are in the in the chat now. It's a bit odd that I saw Marco and now also Vadim join as only participants, but with the timing that really makes me think they want to join Meetecho. Have you has any other any other of you been running into trouble with Meetecho that would make them, like, only half joined?
[00:02:02] Carsten Bormann: I didn't have a problem.
[00:03:05] Christian Amsüss: Let me try an audio again. Marco and Vadim, if you're here and just having trouble connecting with on the audio sending side, please let me know, then I'll wait a bit longer.
[00:03:34] Barry Leiba: Looks like we got looks like we got Vadim, but and Marco disappeared from the Zulip phone link, hasn't shown up yet. Yeah.
[00:03:45] Christian Amsüss: Marco could also just have his lap Marco is active on Zulip banner, so he's like he could it could just be Slack connecting on and off if even if he's not actually here. So I think we can just start now.
[00:03:59] Barry Leiba: Yeah. We seem to have critical mass.
[00:04:02] Вадим Гончаров: I am finally here.
[00:04:05] Christian Amsüss: Hello. Okay. So welcome to this interim meeting of the core of the working group. You've all seen the note well often enough that I just I'm sure it again as a reminder. The main task for today that we'd like to look at is going through the proposed changes for EDN literals and look into how we can continue there and what else is left to be to be discussed and how we resolve other conflicts between those. So based on that based on the thread that we've had on the mailing list, I've assembled what you see in the behind the link and on the on this shared screen here as a list of items that have been proposed mostly for removal and one case for for for as as a fix. Out of those ten, eight to nine have received the support that we put up as a threshold to filter between things where we have to look in more detail for the the longer list of act of checks this has to satisfy. And I'd like to just go briefly through those to to, like, get them all in everyone's mind as present as also talk briefly about interactions. Is there anything you'd want to add or remove from add or or swap around in the agenda? I think not not much swapping with one point, but is there anything you'd want to make sure that we don't miss when we run before we run out of time going through all this?
[00:05:56] Rohan Mahy: So you said you said that you've got support from eight of the 10 or
[00:06:02] Christian Amsüss: five of the 10? Yes. So I did not I did not get see anything any response on the list to the proposal of of limiting back ticket limiters to maximum of of eight. Yep. And the item of removing CRIs had a mail from where I might need a bit of clarification because it was, like, generally, yes, but no strong support. And I think the the I think that, yes, I support this strongly should be a criterion for for removing things at this stage, at least from from from two participants. Okay. So that's why I'm a bit wobbly on on how to count item number six.
[00:06:49] Rohan Mahy: Okay. And then there was I did a I I think I had sent something about not having app prefixes in front of back tick delimited strings.
[00:07:04] Christian Amsüss: That's a good point. I did not find this when I went through the list, but I did notice that at least one of your mails was not sent with kind of not recognized by the mailing list software as a reply to the original thread. So if if if that was that which is why item 10 is at position 10
[00:07:30] Rohan Mahy: Yeah. No worries. Yep. Great. We I mean, we can discuss it last if, you know, if there's but yeah. Thanks.
[00:07:39] Christian Amsüss: I've I've added it to, like, my my editing copy of the list and to the notes so that so that we don't we don't we don't miss completely. Okay. So first proposal that came in was Rohan's proposal to remove encoding indicator AYANA extensibility, which got, I'd say, one and a half voices of support for that. I remember I I also, like, asked originally, like, why do we need this? So I'm, as as an individual, also a bit softly positive here. This, however, did spin off a thread on on what encoding indicators mean. My impression from that thread is that the readings have aligned to the point where it's mapping to the outside, like, to the produced item, but the that item may or may not have encoding so far. So I don't think this is a point that we need to need need, like, larger discussions to see whether this is an unclear aspect of the specification or not. I think main participants were Rohan and and Wadim. Do you agree that you have, like, a founder shared a shared view on that?
[00:09:08] Вадим Гончаров: And what?
[00:09:13] Christian Amsüss: From the proposal to remove the encoding indicators, there was the the spin off thread on how encoding indicators interact with app literals no matter whether they are extensible in there or not. I think that thread has concluded to a state where people have a shared understanding and think that this is represented well also in the document, but that's something I'd like to confirm with you when that is the case.
[00:09:57] Rohan Mahy: I I think that, I think that Vadim and I have specific proposals about where the encoding indicator could be, in this in this case. But I think that we understand the specific proposals that have been mentioned on the on the list. That was my impression. K.
[00:10:24] Christian Amsüss: But to clarify, the proposal to remove the extensibility is not part of your of the remove the encoding indicator extensibility proposal. Right? Okay.
[00:10:38] Вадим Гончаров: Well, if this means just remove an INA registry, then then it's okay. And if for overall extensibility, then well, well, that was set in list already. I'm against removing extensibility in a broad sense.
[00:11:16] Christian Amsüss: Yep. That is then an aspect that I missed from the from from reading through the thread. Barry, unless you have, like, a a more concrete recollection, I'll postpone that for for going through the details there again.
[00:11:32] Barry Leiba: Yeah. That sounds like a plan.
[00:11:37] Christian Amsüss: Okay. Then number two was was limiting ellipsis to precisely three dots, which has a bit of which has a fair share of support. And also Carsten mentioned something like kind of this is clearly no brainer. Obviously, it's a style for it's just it's just a style issue, which I'd like take as a a good sign that this is this is moving the document in the direction where we'll have strong support from the working group for the outcome. Or further knowledge to that, there are three proposals in around removing ellipsis. Joe, one from you that removes them completely. Then another one from you, which I understand to be, like, the light version in case the full removal would not gain traction, that just removes the tag that is introduced ellipsis. And then the third version, number nine, that I suggested based on those which I think would propose kind of a middle ground, which so for I think that issue four probably don't won't need a lot of discussion in terms of whether we should do this because there is some support also for three and nine, which makes the removal of just the tag obsolete. With Rohan and Vadim already chiming in online, which, like, which I proposed as something to supersede three, my main question is to you, Joe, what's your opinion on on item nine?
[00:13:37] Joe Hildebrand: So I still am not quite sure I understand what I as an implementer do when I run into an ellipsis in your approach. Am I allowed to just error?
[00:13:48] Christian Amsüss: Yes. You you no. You're required to just error.
[00:13:53] Joe Hildebrand: So I don't understand then.
[00:13:57] Christian Amsüss: So oh, let let me let me let me make it more precise. It it does create an item in terms of the grammar. So if what you're implementing is is more like a syntax highlighter, which would just as well silently go over other things, then you have something that you can do. But if what you're implementing is something that converts between EDN and CBOR, no matter whether it's the information model or whether it's serialized CBOR, then erroring is the only thing to do. And the let me just switch briefly back into the text of this. I I think the the the the money quote here is that is the text is like, implementations may treat this like an unrecognized app extension, which at least after after item nine, which I really should have oh, sorry. After item five, which maybe I should have mentioned earlier here, makes this makes this just something that can't continue anyway and and creates an error.
[00:15:14] Joe Hildebrand: I can live with that, I guess. I as long as I get the error, that's fine, but I don't understand like, I guess, I don't I still don't understand who's gonna who's gonna implement it where it's not an error. It's weird that it's sometimes an error and sometimes not an error.
[00:15:33] Christian Amsüss: Is it is it is it weirder than application literals that you don't understand?
[00:15:43] Joe Hildebrand: A little. That's fine. If this if as like, the biggest thing is I wanna get rid of the the tag because, I wanna be able to I wanna be able to get rid of the all the rules around what happens when I've got a string and then dot dot dot and then a byte string or a byte string and then dot dot dot and then a like, that's the stuff I really, really wanna get rid of. Mhmm. So that's fine, I guess. I I I don't really understand having productions that always error, but fine.
[00:16:32] Christian Amsüss: I I think that I think the most important use for it is indeed, syntax highlighting and and editable support. But yeah. This It means
[00:16:42] Joe Hildebrand: that those syntax highlighters will have to have their own parsing. They won't be able to use an existing, parser.
[00:16:54] Christian Amsüss: Not necessarily because the parser could do could have options to to flag this, but yes. Okay. So I think that that really makes item four then mood because it is encompassed both in in in by by, three and nine. Next item then, we already mentioned is the removal of code point, 999 for unknown app extensions, which has seen some good support and also outlines a way of how it could be added later. So I think that this is, like, pending pending the the formal checks that we go through by the by the list. I think this is something been doable. Number six is the removal of CRIs, also proposed by you, Joe. I couldn't quite, like, get your mail on on on how you support this because, like, let me just pull it up. So the the point would be that CRI is a tag introduced by the co working group that comes with its own, like, relatively long but defined their rules of how to get from one to the other?
[00:18:26] Вадим Гончаров: Well, I I'd say it's at least it should be made non man optional to implement.
[00:18:37] Christian Amsüss: Yeah. I think I think that was already the intention in the document, but I might have might have misread that.
[00:18:46] Carsten Bormann: There is a closed list of of things that are mandatory to implement, and CI is not part of that list. But I think what what people have been thinking here is that that merely including this in this document might get some some normative force that we cannot control. And given that that moving this stuff over from from the href document of the call working group to this working group was just a device of minimizing the amount of work called the call working group certainly can do another document, pull the stuff over there, and the the cbor- work group can can forget that this exists.
[00:19:36] Rohan Mahy: Yeah. I was kind of on the fence with this one. I mean, I don't want to, like, go create unnecessary process, but the thing that Joe said that, that kind of stuck for me was that it's really not our security considerations. It's the core working groups' security considerations that would apply to this. And, so, yeah, if that's if that's possible, I mean, I think I have a slight preference for that, for moving it into a separate document.
[00:20:17] Christian Amsüss: Oh, thank you both. Well, thank you all three. So then there's the item of removing c style comments in in with not a lot of other than than Rohan and and Joe wanting this to be removed. Carsten?
[00:20:41] Carsten Bormann: Yeah. The main problem with removing this now is that it cannot be added later without creating ambiguities. So we would permanently remove this from the
[00:20:57] Christian Amsüss: Why would there be ambiguities and not errors when a a new doc when a document is encountered that has the dots in there even though they are not
[00:21:07] Carsten Bormann: grammatical? Dots?
[00:21:16] Christian Amsüss: Mark, pardon. I was still mentally on the on the wrong item.
[00:21:19] Carsten Bormann: Yeah. So the the the problem with modifying that syntax is that it is very easy to come up with an example that that passes one way without them and another way with them. So it's not possible to to end this later.
[00:21:40] Rohan Mahy: Yeah. So my, you know, my my main reasoning for this is that that this literal exist has existed for, you know, ten ten years. People are using it, and this was this was a very, very I mean, this was literally added in in, you know, '26 or '25 or something. Right? So it hasn't actually like, the the these comment formats haven't been used in the wild yet. And unlike adding, you know, c style comments outside of quoted strings, this actually, like, has a much has more of an impact if we got it if if there's something out in the wild that has, like, a slash slash empty comment or has slash star foo slash in it. Right? So it changes where you end your end your quotes, and it can do this in a very unintuitive way that's hard to debug. I just think this is you know, adding these was a was a a nonproblem. So yeah. And, like, Vadim just gave an example of something you could do, and it's like, you know, you don't need to you don't need to do that. You can put you can you can express this as concatenate this string where I have h dot quote zero one quote, and then I can have a comment, whatever comment I want there. Right? I can use an end of line comment and keep it inside the quotes. We have a a bunch of solutions. We don't need to have four different ways to do comments inside of, you know, comments of of hexadecimal strings. So, Joe?
[00:23:41] Joe Hildebrand: Yeah. If I recall correctly, this is a place that added a backward compatibility issue as well. Yep. It did. Yeah. So wish that we had used c style comments in the first place because I strongly prefer them, to the the bare slashes. But I don't wanna keep both. And I think we have to keep bare slashes. And, I mean, I I agree with Rohan's point that it's just kinda too late.
[00:24:30] Carsten Bormann: So that that is not a problem that you see with the c star comments in the overall syntax?
[00:24:37] Rohan Mahy: I mean, personally, I think this is a risk that it's the the implication of this being in outside of quoted strings is is a much smaller risk and is much easier to debug.
[00:24:52] Joe Hildebrand: If we're gonna get rid of them, I'd just soon get rid of them everywhere.
[00:24:57] Rohan Mahy: I'm I'm also happy with that, but, like, you know, hey. I I I made a I made a specific proposal, but if I'm also fine kicking them all off off the island.
[00:25:09] Carsten Bormann: Yeah. My my main objective here is to to not create two different sentences for inside and outside.
[00:25:20] Joe Hildebrand: Yeah. I'm fine with that. Let's just remove them everywhere. And I I I think the backward compatibility point is, you know, is the same in both of those situations.
[00:25:40] Christian Amsüss: Procedurally, if if that is a direction in which this is going, I'd like to ask one of you, probably Joe, because you because this was was it yep. No. Sorry. Joe or Rohan, do you have preference of who of you would put that put that as a as a new proposal in?
[00:26:11] Joe Hildebrand: I could do it. Besides, I guess, I'm you know, the more aggressive what Rohan said, it'd be a separate proposal. But, Rohan, if you wanna do it, I think there's precedent for having two, like, competing ones.
[00:26:27] Christian Amsüss: Rohan, we don't hear you, but I think your gesture is is reasonably reasonably recognizable.
[00:26:36] Rohan Mahy: You you got it, Joe. It's yours.
[00:26:40] Joe Hildebrand: Hooray.
[00:26:46] Christian Amsüss: Okay. Going on then, the proposal okay. That that that comment confuses me now. Rohan, you said you have to still support slash space slash quotes for backwards compatibility. Would that not be, like, the outcome of after removing c style quotes?
[00:27:14] Rohan Mahy: Yeah. I was just responding to the comments about isn't isn't aren't c style comments inside simpler, but, like, we that's water under the bridge. We have already we we we can't replace the single slash comments with c style comments. Yeah. So here we are. Yeah. K.
[00:27:37] Christian Amsüss: Backticks then. Proposal number eight was to limit backtick delimiters to a maximum number of I think it was eight here. Eight occurrences of backtick following the the argument that this is something intended for human consumption and humans don't really do well with recognizing optically whether something is is, like, eight or 10 things out outside of outside of recognizing LEGO bricks. However, I have not seen any positive response to that. So I don't think that this will move the document in a direction where we have better consensus with this being removed than without. Item nine is something we've already talked about. So I won't go into the into anything further here. And the last two ones are those that I missed in the in the sequential that the mailing software missed to assign. That is number 10, the removal of non JSON decimal numbers, which means that which is about lead allowing whether or not leading zeros can be elided, whether the signs are optional can be added or not. This has seen some support, but I also have Carsten in the queue. So, Carsten, please say something.
[00:29:09] Carsten Bormann: Yeah. So so really this seems to to address three different things, which I think we should be discussing separately. One is do we allow plus signs in decimal numbers? JSON doesn't. We could, we we could not. I I don't have a particularly strong opinion, but it it came up during the discussion we had that that made the whole thing happen. So it it's in there right now. So I I declare no no position. The second one is do we want to be able to remove insignificant zero remove insignificant zeros? So can you write three dot or dot three as floating point values. I think there is good reason to do that because just about every programming language out there allows that with very few exceptions. So when you want to support copy paste ability from other sources, you are quite likely to run into this. So this is about insignificant zeros at the start or at the end and removing them.
[00:30:37] Rohan Mahy: I think we need to talk differently about removing insignificant trailing zeros from from extra
[00:30:44] Christian Amsüss: Yes. Extra leads. And
[00:30:46] Carsten Bormann: the third one, the third point, is that the current text allows adding insignificant zeros at the start or at the end. And points out that this could create the octane number confusion that we are all very familiar with. And, well, that that is maybe actually a a security consideration or usability consideration that hasn't received the the amount of attention that should have received. So maybe we can actually go ahead with not allowing to add. We talked about removing before now. Not allowing to add insignificant zeros at the start of of the grammar. So 0030 would not be allowed because some people might be copying that from a source where zero zero three zero actually is an octal 24. So these are the three different things. I don't really care that much about plus. I really care about being able to write three dot or dot three. And let's not do zero zero three zero.
[00:32:08] Christian Amsüss: So just to get a a brief, like, room temperature, Rohan, is that some is is is that the folk is that would is that something you would support if proposed as a standalone change?
[00:32:25] Rohan Mahy: I'm I'm you know, I think my preference is still to have the canonical JSON form. But, you know, I I think, you know, I've I've seen it's not a ton of work to make it to to to make things work with that. It's also not a ton of work to make tools that that generate the, like, the the the canonical format. So, yeah, I'm I'm a little bit on the fence, but like I said, I have a a a slight preference. Joe was the other you know, was one of the other people who responded on this. Lawrence, I think.
[00:33:06] Christian Amsüss: That that that would have been my next people to ask. I'm seeing that I'm seeing that Lawrence is not here. Joe Hildebrand?
[00:33:16] Joe Hildebrand: I mean so I think I would have used almost exactly the same words Rohan just did. Like, I could live with it, but I think I'd prefer it to just be JSON.
[00:33:31] Christian Amsüss: Okay. Well,
[00:33:38] Вадим Гончаров: confusion with octal numbers, yes, is significant for security, so I support removing leading zeros here. For others, copy paste stability is a very reason I I have no strong opinion yet.
[00:34:01] Christian Amsüss: K. Thank you.
[00:34:02] Вадим Гончаров: Maybe maybe later, not today.
[00:34:06] Christian Amsüss: Yeah. I think that given that we are trying to find a case where, like, we get working group on consensus on it, not necessarily the thing that everyone is most happy with because we won't get that. I'd like to ask you, Carsten, whether you could, like, do submit a proposal that is, like, the the minimal thing that you that you think can pass and that addresses the security aspects.
[00:34:37] Carsten Bormann: Yeah. We haven't really talked about plus yet, but what you just said would exclude plus.
[00:34:44] Christian Amsüss: If you think if you use your seems seems seems a bit like no one has an opinion there. So
[00:34:56] Carsten Bormann: Yeah. So I'm not running into copy paste victims that that have plus in them a lot. But that is, of course, my personal perspective, and I I don't know all usages of of SIBO. So I I would expect that we would put that in, but other people maybe don't like it. So I'd I'd like to hear something about plus. The other thing is we we do want to support 3 dot and dot three, and we don't want to support zero zero three zero. You
[00:35:37] Rohan Mahy: know, I mean, I guess the question is, the was an original proposal here, which was just to do it the way Jason does, which is easy to explain. So Carsten, you know, has has given, like, you know, moderately compelling reason for why he wants to add this you know, make this small change. I'm just kinda curious, like, is the how do other people feel? Is there a benefit of simplicity of just just doing this proposal as as written? I don't know.
[00:36:25] Joe Hildebrand: I think the places where it looks like JSON but aren't JSON are should have some better motivation than what we currently have.
[00:36:50] Christian Amsüss: Taking yeah. Hold on.
[00:36:52] Rohan Mahy: Yeah. Oh oh, yeah. There was another thing that I noticed when I was writing this up as well. When I was looking at the grammar for the for the other bases, and the other bases, of course, all require a zero a leading you know, they have a zero zero x or zero b or zero o. Right? So yeah. I I you know, it's it's gonna surprise fewer people who are trying to decode it if it just looks like Jason.
[00:37:38] Christian Amsüss: Just on on on the topic of, like, what are your opinions on on expectations? Just as an individual, I'd expect this to be I'd rather expect this to be different and fix a few of the oddities that Jason did like we did around around Unicode handling. But, yeah, that's one of one of many opinions in the in this or that direction here. So I don't think we can really conclude here, And I think I'd stick with, like, Carsten, if you want to make a proposal to gather support for, please do that. I think to
[00:38:35] Joe Hildebrand: the extent that your argument says that JSON is just wrong and this is fixing a long time JSON problem, it might be more compelling.
[00:38:49] Carsten Bormann: Yeah. I would say they should JSON is wrong, but JSON doesn't offer some of the copy paste ability that that 3.n.3 provide. I I really tried finding any communication from from the early two thousands that indicated why this was done, and I didn't find any. So I I would prefer to actually respond to to any such argument, but no such argument was was made that I can find. Excuse me.
[00:39:30] Joe Hildebrand: Yeah. Go ahead and make the proposal, and maybe we can move on today.
[00:39:37] Barry Leiba: Will do.
[00:39:38] Christian Amsüss: Yeah. K. And off that list, and Rohan reminded me that I did not find this, and I'll update the list after the meeting, was the topic of removing prefix option from back tick quota strings. And, consequently, I don't have the list of, like, how could support this got. Yeah. Maybe yeah. I I really don't I I I do remember having seen that mail, but I do not find it right now. So I think that we'll have to leave that for for digging it up unless any of you finds the link faster than I do.
[00:40:49] Rohan Mahy: So I just, you know, I just looked at the Rust playground for dot three and three dots. So as literals, it doesn't this doesn't work. I'm gonna try just now with strings.
[00:41:18] Christian Amsüss: Are you sure? Because, cons, this, does compile for me. So it's it's, like, halfway there.
[00:41:51] Rohan Mahy: I think this is a new clippy clippy error. But yeah. I'm checking the into, you know, the, like, parsing from string right now. So
[00:42:03] Christian Amsüss: Yeah. That that will be input to number 12 or number 13 as things come in.
[00:42:10] Вадим Гончаров: Mhmm.
[00:42:12] Christian Amsüss: K. So going back to the going back to the goals for today, on the topic of is there anything that was not said yet? I do expect two updated proposals, One more comprehensive on removing c c style comments and one go like, doing the security critical aspect of 10, but not the not not some of the others to to yet come in. I think we've successfully talked about the interactions that the the item issues have. And is there any clarification on on proposals that is pending where you want to use the high bandwidth situation that we still have to to clear up misunder possible misunderstandings?
[00:43:14] Rohan Mahy: I want to I want to talk a little bit about float because I thought, you know, hey. Like, if we're if we're going minimal, maybe I'll write a proposal to get rid of float. But I think that having a way to express NaNs is is important to be able to express every valid CBOR, and I thought that it would be nice to have that in the base document, and it's float_b16 not hard to implement. However, I also thought you know, woke up one morning and was thinking, you know, maybe it would have been better if float actually took if float was, you know, was in the I'll write some syntax here. If it was basically an array of significant and and an exponent, right, that this might be more natural, that you could potentially have different array formats for you know, you could have a different array format for NaNs. Right? And this would yeah. So, you know, I was thinking about it, and I was like, well, you know, does does anybody like this better? I mean, I guess the question is, is that better than having, you know, float and then some hacks?
[00:44:43] Carsten Bormann: The the problem is that what what you wrote into the chat actually doesn't say which kind of float we have. Do we have a sixteen, thirty two, or or 64?
[00:44:55] Joe Hildebrand: Yeah. Does Yeah. By the time we specified all that, it's just gonna be a lot more complicated than the hex.
[00:45:03] Carsten Bormann: Yes.
[00:45:09] Rohan Mahy: Yeah. I mean, I was thinking we would use the encoding indicators to do that. But yeah.
[00:45:22] Christian Amsüss: The current document says that encoding indicators can always be ignored. So
[00:45:27] Rohan Mahy: Okay. So I'm fine with leaving the float float as is in the document. The team has a seems like the team has a specific concrete proposal.
[00:45:50] Carsten Bormann: Yeah. I think it's close.
[00:45:52] Вадим Гончаров: About float or about r? To have row. It's we don't need to to decide the fast. I also have two another proposals, but I didn't see yet find find a way to express them in ABNF. Those are for optional commerce in maps and moving the encoding indicators to front.
[00:46:41] Christian Amsüss: Are those items that you still plan to submit?
[00:46:48] Вадим Гончаров: Yes.
[00:47:05] Christian Amsüss: Okay. So then I suggest that we take about a week will will a week be sufficient for everyone to to submit their their additional items?
[00:47:23] Joe Hildebrand: Yeah.
[00:47:25] Rohan Mahy: And do we wanna do we wanna talk about this the raw string extensions proposal or the people need
[00:47:37] Christian Amsüss: to it? The raw
[00:47:43] Rohan Mahy: Mikolai posted in the chat.
[00:47:46] Christian Amsüss: Ah, okay.
[00:47:46] Rohan Mahy: To it.
[00:47:50] Christian Amsüss: Is this something that would like, what what I'm not sure about that our our our raw string proposal is ah, okay. So it it would this would be a replacement for float because there is some
[00:48:03] Rohan Mahy: It has nothing to do with float.
[00:48:05] Christian Amsüss: Okay. But then but then it is an addition and not not fixing something that's wrong with this document. Right?
[00:48:15] Rohan Mahy: No. Sorry. The the the link that has a proposal for a new thing called r for raw strings. I had a proposal that says, like, if you do a raw string, you know, back tick encoded string, that that you we don't put app prefixes before that. So if you if you have an app if you have an app extension, you can that can always be the sort of canonical form of an app extension is the the extension with the double with the double anchor bracket. And you can always represent instead of, you know, URI back tick back tick from URL back tick back tick. You can rec represent that as CRI angle bracket angle brackets back tick back tick your string, and you can put whatever comments in it. You can, you know, you can do whatever you want. You can you can, you know, you can append it to something. You can put another extension in that appends it to something else. You can do whatever. But it's sort of the canonical form theory is that, you know, there's a canonical form. You can do anything you need to do. It's just that we don't need to add a new syntax to have another way to go do these extensions. Yeah.
[00:49:42] Christian Amsüss: You need
[00:49:43] Joe Hildebrand: to understand.
[00:49:45] Christian Amsüss: I think as I understand, that proposal is out and it might not have gained any support because it was somehow not not well linked or visible. If, like, if you have if you have the the archive link, please please, like, put in the chat or or send it to me, and and we'll bay basically, we can repost that on the list so that people can can have thank you. So I'll just pull this up. So my suggestion is, like, people have seen this now again in the in the right place. Please have a look. Please answer on the mailing list whether this is something that makes sense sense to remove, and then we can continue from there. Great. Thanks. Barry, did I miss anything or anyone really?
[00:51:34] Barry Leiba: Nothing that I can see. I think we're good. So it sounds like we are close to finishing this up. Thank you, everybody.
[00:51:52] Christian Amsüss: Thank you.
[00:51:52] Вадим Гончаров: So we have about two or three questions for next meet and to discuss in this. Yeah? Or or more.
[00:52:04] Christian Amsüss: I don't think that the those those those new items will necessarily need need discussion in the interim meeting. They'll be mostly for, like, put them up on the mailing list again. Let's see what the responses are. And if there is if if there are competing proposals that have strong support for both, we probably pull them up in the next interim meeting. Otherwise, this should become a list that that Carsten can work on to bring document into a state where we can finally have the working group, everyone be in a in in rough agreement that this is what CBOR should be.
[00:52:43] Barry Leiba: Agreed. And so, the next interim will likely be to talk about, the serialization last call.
[00:53:00] Carsten Bormann: Which is not has not ended by then. Right?
[00:53:04] Barry Leiba: Well, it yeah. We've extended it because of the holidays and Lawrence being out. So
[00:53:17] Carsten Bormann: Yeah. I I just wanted to point out that that we cannot look at the result of the regular class call because that isn't in by the time of the next meeting if I count correctly.
[00:53:28] Barry Leiba: We can right. We can do we can discuss things that have already been brought up that need to be discussed.
[00:53:34] Carsten Bormann: That's that's
[00:53:35] Barry Leiba: the point.
[00:53:36] Carsten Bormann: So I I would phrase this. We can ask people to actually submit any substantial comments before well before that Yes. Meeting.
[00:53:46] Barry Leiba: I see where you're going. Thank you.
[00:53:48] Carsten Bormann: And you you define what well before that meeting.
[00:53:51] Barry Leiba: Please don't wait till the last day on the serialization last call. Let's try to get as much as possible ready for the next interim. And as Carsten says, ready doesn't mean the night before. Try to get your comments in so people can digest them.
[00:54:12] Carsten Bormann: If we're done with this, I have one question. There are still a number of pull requests that I haven't been able to merge. I think a lot of confusion right now is coming from these pull requests not being in there. And I would like to to get a little bit of help on on when these pull requests are getting their their big moment.
[00:54:55] Christian Amsüss: I think the best we can do here is that that Paul, Barry, and I look through them and look into what is what we what we all agree on is really just editorial changes and what are what are substantial ones.
[00:55:10] Carsten Bormann: Thank you. That
[00:55:11] Barry Leiba: sounds right.
[00:55:12] Rohan Mahy: Perfect.
[00:55:20] Christian Amsüss: Okay then. Thanks a lot. I'll stay a bit longer in in here to look through the chat because I missed a lot of the things that we are going on there in in parallel to talking. But I think we are well on time for today. Thank you all for your input. Read you on the mailing list and hear from you in two weeks. Yep. Thanks, everybody.
[00:55:43] Carsten Bormann: Thank you. Ciao.
[00:55:50] Вадим Гончаров: Thanks. Bye.