Session Date/Time: 15 Apr 2026 14:00
Barry Leiba: Well, we are at the top of the hour and have critical mass, it looks like. So why don't we get started? The priority for this session is to do whatever we need to do with draft-ietf-cbor-edn-literals. I have to say I'm surprised at how many changes there are coming up. I was expecting that we were close to being done, but let's go ahead and have the discussion. And Carsten, you have slides, right?
Carsten Bormann: Correct. Okay, so I didn't know that we were going to have another item. As I said, I think the partial serialization discussion is important, so we should try to get through the EDN stuff within half an hour. So, yeah, the question is what needs to be done after the publication of -22? And -22 includes the C-style comments, which is issue number 82. I think that issue is still open. We have had some discussion. Not everyone is super happy about the result, me included, but it seems that this is what we are converging on and nobody really has contested that convergence for a week or so. So I think unless something comes up today, I'll close the issue. We can always reopen it if we find a new consideration here, but I think we are done with that.
Next issue: the padding tolerance. So, Laurence brought up an interesting point, and we had some discussion. And, yeah, the discussion essentially was we don't want to make things more lenient. So we probably should have no action here. So we stick with the union of Section 4 and 5 of RFC 4648, and we require either sending no padding or the correct padding according to RFC 4648. And maybe we should spend a little bit more editorial work to make sure that we really say that, but I think that's what the ABNF says at the moment and we might have to improve the text a little bit, but then we can close that one as well. Any issue on that?
Okay. Yeah, so I naively asked whether we can put the two... go ahead.
Rohan Mahy: Go ahead and finish your slide, please.
Carsten Bormann: Yeah. So I naively asked whether we can do the should-be-non-controversial float and same EDN extensions. Apparently they aren't non-controversial. So I don't want to waste our time here. So let's keep it in the separate draft and process that in time. This CBOR Test Vectors project can probably live with that at the moment. So I think we can also close issue 86 as won't-fix.
Rohan Mahy: Do we have—if we split this, do we get a different answer? Like if we say, do we want to incorporate just float, do we get a different answer than if—or are there enough people that object to float?
Carsten Bormann: Well, Laurence doesn't like float and you don't like same. So I didn't want to engage in a discussion about either at the moment. We can do that in time when we process the documents. I just thought these should be entirely non-controversial. They looked that way two weeks ago.
Thanks. Okay, so again, we're not discussing this today and we'll wait for getting to this in time. Then we have two main points here that I was not going to try to summarize from my point of view because that's probably not productive. But essentially there are a number of points and issues 88, 91, and the pull request 92 that essentially repeat the discussion about going for a monolithic parser and a cathedral model of running extensions. So I'm sure Rohan would describe that differently. And we also have two issues that talk about the boundary between encoding and data model, and we probably have to spend some time clarifying this some more because EDN is in this weird situation of being used mostly for representing data that belongs at the data model level, but it is also a diagnostic notation, so it has ways to show you encoding information. So, yeah, we have to find out where we are. And we had a pretty interesting discussion today about, for instance, expressing map sorting and or deterministic encoding, one of the deterministic encodings, by using encoding indicators, which actually were meant as the extension point that we can use to extend the diagnostic capability of the language. I think we are progressing this on the mailing list quite well, but of course if we have high bandwidth, we should try to discuss these two items here in the meeting.
Rohan Mahy: So, I specifically wanted to talk about the BNF, the integrated BNF, as I don't actually believe that this is cathedral versus bazaar. I do—while it is true that I do want to have a mandatory-to-implement, even if it doesn't include all of the extensions described in the draft, I think that's certainly the simplest thing to do is to have an MTI of everything that's in the draft. But the discussion about integrated BNF, I think that that is something that we can do separately whether we have a bazaar or a cathedral style model. And I think that the, you know, the PR that I wrote shows specifically how we could go and use these extension points. I also think that, for example, using the double angle bracket notation with some of the existing app-string prefixes like 'h' and 'b64' is totally unnecessary. I don't think it adds any value. And so I think I think that basically we should use a specific extensibility mechanism if it serves us, because the specific grammar to be used inside requires it.
Carsten Bormann: Okay, I think this is not a new discussion. We have had discussed various properties that are useful for the bazaar model, and one of them is isolation. And requiring integrating things is not helping with isolation. And as an implementer, I'm not at all happy with having to recompile my ABNF each time I add an extension. In particular because extensions will develop in parallel, and it really helps if you can progress these independently from each other and actually include both without running into isolation problems.
Rohan Mahy: You can use—you can use the slash-equals to include, you know, zero, one, two, 17, whatever of your extensions.
Carsten Bormann: I understand that the SIP world has lived with this for the last couple of decades. We try to do better. So the—
Rohan Mahy: And I think you've made a monster. I think you've made something that's much worse. I've implemented both. So, you know—
Carsten Bormann: Well, I've implemented both as well. It's not particularly hard. The difference is that you don't have to touch the main ABNF to add an extension in the isolated model.
Rohan Mahy: You don't need to touch the main BNF in the with—if you write a new extension either with the integrated approach.
Carsten Bormann: Well, you have to touch it in the sense of you have to recompile it with the new slash-equals in there. And that is a big difference.
Rohan Mahy: That's an artifact of the mechanism that you use to use these BNFs, right? But—
Carsten Bormann: Well, the problem is that these are grammars. And grammars are complicated in certain ways, and particularly in ways that are mathematically provable, not fixable. So we will always have the complexity of fighting it out between different extensions. And doing isolation from the start really is a much better approach to this.
Rohan Mahy: I mean, when most people go and actually implement, you know, a particular choice of a set of extensions, the way that this has been done for decades and has been very successful for decades has been to end up with a single BNF. You know, if you want, for example, like I gave the example of a code editor plugin that does code coloring. It needs to know where the starts and ends, particularly with the, you know, when we start using the double square bracket, the double angle bracket model, we're going to have to be able to deal with a lot more stuff that's inside. I just—the way the BNF is written right now, it feels to me very clunky, it is hard to read, and it allows a bunch of things which, you know, frankly are not—with existing types that are not needed, that can be expressed equally clearly with the default, you know, the default app prefixes. And the BNF can be expressed in a very simple, direct way. And even as you add extensions, like all of the extensions, the concrete examples for extensions that we have can be—you know, I've tried to do the work to show that when I did that in the PR this morning, during breakfast, I was able to come up with this BNF, right? So any idea that this is hard to come up with an integrated BNF, I think is provably false. And the idea that we are, you know, this is far outside of the norm of what we have done in IETF. You can still do what you want to do outside of the norm by having, you know, by not parsing in a single pass the things that are inside of the identifiers and you can parse them as if they were extensions and then you can still go do the kind of thing that you have been doing.
Carsten Bormann: Yeah, the reason this was so easy to do is that EDN as it is provides for that. We have both integrated and isolated parsers. The question is how do we do the next extension? And I would prefer not requiring people to do integrated parsers, but being able to live with isolated parsers.
Rohan Mahy: It's not requiring, it's a question of the default. And the default we've had for, you know, everywhere else in the IETF has been integrated parsers.
Carsten Bormann: That's not true. If I have a JSON document with a URI in it, the JSON parsing is happening first and then the URI is parsed. And that's the default. That's the normal way in which we combine data representation formats with each other.
Rohan Mahy: But JSON does not define an extension for URIs. JSON defines strings and what you put in the strings is up to you. That is not an extension point, that's a garbage pit. Those are different. What you're describing is a garbage pit masquerading as an extension point. That's not what we have been selling the working group and the IETF. If you want extensibility instead of a garbage pit, then we need to have at least the default of an integrated ABNF.
Carsten Bormann: I don't follow. I really don't follow. So, what is the default here?
Rohan Mahy: What I'm suggesting is the default is that we have a list of known app—known app-strings for single quoted, known app-strings for—known app extensions for the double angle bracket extensions. And then as we use them, you—when you say, okay, I've defined CRI or ref or whatever, right? You put the BNF for your specific extension and then you put 'known-app-string' slash-equals and the name of your token, and then you get your new token. Boom.
Carsten Bormann: Yeah, so you have to create an integrated parser and, yeah, it's not trivial to create an integrated parser.
Rohan Mahy: I mean, I did it this morning during breakfast.
Carsten Bormann: No, you didn't. You stole mine.
Rohan Mahy: Carsten, with respect, I wrote in a PR—I went and rewrote the ABNF from EDN the last time and you didn't like it and you rewrote a bunch of other things. And the fact that, you know, we basically we went several weeks with sort of partially having a discussion and then had a discussion while you were changing the BNF. I mean, at the point that I created the BNF, it was it was something that I created pretty much from scratch and was totally reasonable. So, I mean, the point of all of this is that an integrated BNF is not actually that hard to do whether I borrow productions you've already written or not. But I produced what I consider to be a fairly elegant one that was easy to extend, that was easy to borrow from, where you could take productions for, say, comments if you wanted to have comments inside of your extension. Right? All of those things were possible. You just needed to go borrow the correct productions. And we could have even documented that. But, you know, saying that it's hard, I think that flies in the face of the evidence. If you think it's hard, I will do it.
Carsten Bormann: Well, I would like to hear what Christian is saying about this.
Christian Amsüss: I'm just trying to summarize, to find out a precise point here. Carsten, when you said that this was easy because it was done this way before, what I understand this would mean is that when someone would do new extensions, they would not have the guidance that was there by the extension points that you've already put into ABNF. So you're claiming that Rohan's work in the morning was easy because it was implementing something that you already designed to be doable this way. So if that is correct, how would this work out with—like, what would happen if someone who does not have the background of our discussions were to create a new extension? Rohan, would they have a tool which would help them show those properties that you claim are that things are still doable well in a single-pass—in a dual-pass parser as well?
Rohan Mahy: It would be to write, you know, in the—so, like often when people have BNFs that are non-trivial, you write an annotated, you know, you write chunks of the BNF with annotation in between, right? And then you also have—you can have an appendix, you have the completed, the full ABNF. So you can take a section of text to describe the productions that are potentially useful in extensions and you say, okay, like here define the ABNF for the thing that goes inside of the single quotes or inside of the, you know, inside of whatever syntax you're asking for. And if they define those things that require, for example, anything that is not a restricted character in that scope, or if they want comments, they use one of the handful of those productions that represent those concepts. So typically, you know, when I did the previous PR, there were either three or five of them depending on if you wanted to be able to use all of the comment types inside of your extension. In the case of someone who doesn't want to use any of the quoted characters, then the difference between the two BNFs is effectively zero. Right? So if I'm doing IP and DT, they don't use those characters. They don't have comments. There's no difference.
Carsten Bormann: Yeah, that may be one of the reasons why I threw out CRI, because those don't happen to have these nice properties.
Rohan Mahy: Well, CRI works pretty well. It doesn't require—it doesn't require comments.
Carsten Bormann: Yes, but it does contain characters that would terminate single-quoted string, for instance. So this stuff is not easy. It's easy when somebody has already done it. And the fact that you could just delete all the isolated parsers and put the integrated parsers that were already there into the ABNF doesn't convince me very much. And the fact that you had to delete CRI to actually do that—
Rohan Mahy: I did not have to delete CRI to do that. In fact, I wrote up productions for CRI as well. And the fact that I had previously written a PR that deleted CRI, I just happened to have copied from the wrong—I had not saved—I had some unsaved changes when I changed branches, but I did go back to main and then create a new branch, but then when I saved the file, I had already had unsaved changes from the previous file. So that's why CRI was removed. We don't have to remove CRI to do this. Adding CRI is not difficult in this case.
Carsten Bormann: Okay, for a definition of difficult. So this is really hard to discuss with just IP and DT as examples, because these actually have very simple grammars. So even in an integrated parser they don't look too bad. But as soon as you get more complicated application-oriented data like URIs and CRI, it becomes more interesting. And we don't have that data point. But Christian really points out that the way this would require every extension supplier, every extension writer to generate an integrated parser just so we can do single-level ABNF parsing is—
Rohan Mahy: So let me tell you why I think that's a great thing. I think that's a fantastic thing, because if you are an implementer who wants to do things, you know, who wants to have a fast parser, and wants to have it in a single integrated BNF, and some extension developer comes along and they do something that makes that difficult or impossible, then you're the implementer stuck with the work of going and trying to make somebody else's extension work that did not consider this. And I think that it's reasonable to ask an extension developer to go and do that work and make sure that it's possible to go and add that to EDN. They don't have to add it with every combination in the world, they just need to go and add it to the basic extension point. That's all.
Christian Amsüss: Don't we have a tool already that creates those nested ABNFs? I think Carsten wrote that up. So this can be done mechanically, right?
Carsten Bormann: It can be done mechanically. The result is really ugly.
Christian Amsüss: It's ugly, but it works. I'm not worried about that. So the direction I'm more worried about is the other direction. When someone sees that the style to define new grammars is to write an ABNF and they are not an ABNF expert because people—this is supposed to be extensible by more people than like the group of us sitting here getting grey together. If people are using this who do not have the background of knowing ABNF by heart anyway and reading through the appendix to see what the good productions are that you could use, then they might define extensions that don't even work in two-pass modes anymore because they implicitly break things. And checking mechanically for that kind of—we can probably check mechanically for that, but we can't force implementations to check mechanically on that and then people start using this pattern that we establish. But if the pattern requires an amount of experience that is not so widespread and people follow the patterns that we are using and then might need the help of, I don't know, EDN doctors to make sure that things are okay, then this is problematic for future development.
Rohan Mahy: Christian, I think my experience is that if you have a simple extension like IP or DT, even CRI is of moderate—only moderate complexity. That honestly, for you to go and write that extension and make it work in the double-pass situation, you're probably—unless it's trivial, you're probably going to need help. If it's trivial, both methods are going to work fine. If it's not trivial, you're still going to need EDN doctors. You're still going to need to go and ask for help.
Christian Amsüss: What I expect is that people would be using extensions where they don't develop their own grammar but they click something together because they are using, for example, in the CRI extension the URI grammar, which most people also don't know by heart but they basically take a URI parser that's somewhere around. And when they then go and take an ABNF from somewhere, put it in there, and it works for their tools because their tool happens to be a single-pass parser that effectively when there is an open parenthesis single quote says, 'Oh yeah, we're in an open parenthesis, we continue now until we find the single quote close parenthesis and continue there.' That will work for them because they follow the patterns that we establish, even though our design says that things should work for both kinds of parsers. And they might not even notice because the open parenthesis single quote situation might be a rare occurrence there. But all of a sudden they've built something that works for some implementations and doesn't work for other implementations. So that's what I'm worried about.
Rohan Mahy: Okay, so are you worried about the case where somebody breaks single-pass parsers when they write a double-pass parser?
Christian Amsüss: No, I'm worried about the other direction. They are building their extension with a single-pass parser and in such a way that it breaks the requirement that things are still properly escaped and can be converted to tag 999 etc.
Rohan Mahy: But you're not worried about the other direction. So somebody goes and creates a parser that is unimplementable, that is incredibly slow, that you can't use with PEG grammars correctly, like that's—
Christian Amsüss: Slow? No, it won't be ambiguous, it's just slow. And people in that situation—
Rohan Mahy: They can create grammars which are ambiguous. They will—if they create a two-pass grammar by taking the ABNF that we have and plugging in some ABNF into the second pass that they got from anywhere, any arbitrary ABNF, then as far as I understand, the tool that Carsten wrote will create for the single-pass users a grammar that works. It might be slow and it might have potential for optimization, but the people who are combining those grammars will generally not be in control of that grammar they plug in because it's an existing grammar like the URI grammar that we have, for which we're moderately lucky that things work, or the IP grammar for which things are very easy. But they won't be in control. So if things are slow for a single-pass parser, that's really not something that the people who just define the extension point that combines CBOR with whichever other domain specific language are in a position to influence. If the single-pass parser is slow, then maybe the users of the slow parser might need to consider their choices in parsers, but it will work. It won't work if it's defined in the other direction because then all of a sudden it's a grammar that does not follow the rules of 'if there is a single quote, then either it's escaped or the string ends.'
Rohan Mahy: By using the existing productions that I described, for something that is straightforward, it should just work. For something that is non-trivial—I mean, the problem is is a lot of those grammars that are floating around there, they were broken. They weren't correctly specified. When I did the PR that I did, you know, before we did our refocus, that PR I went and re-read the BNFs for IP and for the canonical reference for the date and for URI references. And I like rewrote those BNFs because they weren't very good. Some of them were not even right.
Christian Amsüss: Isn't that just making my point? Doing ABNFs is hard. And if we define—if we use the two-pass model as our main frame of reference, people getting ABNFs wrong won't break the complete parsing model.
Rohan Mahy: That's not been my experience. They're going to make broken parsers if they do something non-trivial whether they do single or double parsing. The issue is whether the output is going to be useful by people who want single-pass parsers. What can go wrong in a two—in an extension point defined in the two-pass mode that makes things completely impossible for single-pass other than a missed optimization because the tool to convert from two-pass to single-pass is not optimal?
Rohan Mahy: So most of these—so we have multiple parameters like sequences that we define in with the double angle brackets, right? So there are a number of things that could go wrong there. Like basically, if somebody creates a BNF for a two-pass parser and then they use, you know, it's going to be very common for people to go and ask an AI to go generate some examples that use this. Some of those examples are going to include characters that they did not consider originally. Those examples then when they're put through the first-pass parser, they're going to have results that are different than the results that the creators expected if they don't know BNF well enough or if they're trying to—you know, if they're both are doing something moderately complicated and don't know BNF well enough.
Christian Amsüss: How? And the answer of course is not to require ABNF for the extensions. So if somebody knows what a URI is, they can build a CRI parser without using the ABNF that is in the document. The ABNF in the document is just useful for parser-jockeys that know how to throw this at their parser generator and get some value out of it. And I think that is really an important property of the isolated approach as well, that we don't need to burden the extension writers with doing a correct ABNF.
Rohan Mahy: I mean, everything that you guys are talking about is shifting work from extension developer to implementers.
Carsten Bormann: No. We're shifting work from implementers and extension developers to the architecture.
Rohan Mahy: You're just making life harder for the implementer. We look at the complexity of this spec since -18 compared to -22. Look at the complexity of implementing the BNF that was in the PR that I wrote versus whatever version that was, -16 I guess maybe, of that BNF. The ability to go and write—it's much simpler for an implementer that is doing single-pass and frankly that's what anybody who is serious about performance is going to be doing whether they know BNF well or not.
Carsten Bormann: So when we discussed this on the mailing list, I don't know who said that, somebody said we could use a Wiki or something like that.
Rohan Mahy: That was you who suggested we use a Wiki for the single-pass.
Carsten Bormann: Well, all the components are in the specification. So the Wiki would really show how you put these things together to have an integrated BNF. And yeah, we should provide that. We should make the implementer's life easier. We missed out on a few places where we could have done that for CBOR in the past and we should get much better than that. So that's why there now is a Wiki page for useful CDDL and so on and so on. But saying something is a default doesn't make sense because an implementer may have priorities. The implementer may want to provide an implementation that is robust and makes use of isolation and so on, or the implementer may want to write an implementation that is very fast even though we haven't really proven yet that this gets faster in an integrated parser. I think the important observation here is this is not SIP where the text-based protocol actually is described by this ABNF. This is a diagnostic notation. And so the requirements for interoperability are different from the requirements we use for actual interchange.
Rohan Mahy: I don't believe that. The fact is we've got—if we want this to be useful—I mean, JSON was tremendously useful as a format that people understand that people can use. YAML is an incredibly popular useful format people use it all the time. Even TOML. Okay? If we want people to be able to use this, if we want it to be as successful as those formats for being able to express stuff in a human-readable form that you can easily convert into what is frankly a very nice representation format, then making it easier for people to implement EDN is critical. I think most of us agree with that. I just have a very different set of experience perhaps, but I've seen this movie before and it has not gone well when we've done something that has made it hard for implementers to go and frankly, you know, frankly having tons of extensions. It's great if the ecosystem is flourishing so much that we want to add a bunch of extensions. But the fact is is that the tooling has not caught up to even the base EDN draft because, you know, it's been stuck. And at some point we're going to have to take a leap of faith with the choices that we have made for extensibility. But it's not like we've got a hundred people who are lined up that are like, 'Hey, I want to go write extensions.' And it's not like most of those extensions are terribly complicated and need, you know, need multiple nested comments. And in fact the motivation for example for quoting hell is been 'I want to put in an entire programming language like ECMAScript or Lisp or I want to put in regular expressions, complicated regular expressions inside.' But we don't have those extensions written even. Like nobody's actually proposed an actual extension that does that. I think that's a red flag. But looking at the comments, I'm not seeing anybody else who's supporting the position of making life easier for implementers, so I'm going to get off my soapbox.
Carsten Bormann: So it's interesting that you mention YAML because YAML actually is extensible as opposed to JSON. And the extension model of YAML is one where you have strict isolation. So I think the YAML people knew something when they designed this. So I'm all for making life easier for implementers, but I actually think the isolated model is much easier to implement than the other one. So, yeah, I rest my argument. We need to make progress at some point. Christian? Okay, so Christian doesn't want to say anything.
Okay, I'd really like to spend some of the 15 minutes we have on the encoding versus data model issues that you created, Rohan. So one question was can we indicate encoding properties in EDN that would support deterministic encoding in some ways? So right now the document doesn't say anything about that. The serialization document says something about data model support for embedded CBOR, but nothing for data—nothing for support of actually doing encoding to encoding specifications to the top level. And it certainly makes sense to be able to specify a serialization constraint in a language that already supports encoding to some extent. Now this won't be easy for implementers, but I think I would like to explore that space. And we had a discussion on whether this should be an application extension in EDN or should actually be an encoding indicator. And I would like to hear whether there are points for moving this forward.
Okay, that doesn't seem to work very well. People don't have an opinion on this. So... oh, well, won't we have problems with namespaces or something when it will come to encoding indications?
Well, there is a registry for encoding indicators. So if we want to use encoding indicators for indicating deterministic encoding or something like that, then we could just use that registry. And I think I actually gave an example in mail, I can't find it right now, how this could be done. So it's not really very complicated and I probably could implement this in four lines of code. So I think it's worth exploring even if I'm not entirely sure we should spend more emphasis on encoding indicators because that's kind of distracting from the main point.
Rohan Mahy: Carsten, just to—sorry Vadim, do you want to continue?
Vadim Goncharov: Oh, well I tried to look at chat and both to listen, so I essentially missed what Carsten said. I've heard about IANA registry and that's all. What I'm talking about is that example where you have both '_C' and '_L'. Yeah, I just posted—I copied that to the chat in case people haven't got the mail. Yeah, about exactly that example. I see that at least these are too short, and if we have them longer, will we have how to say it... maybe not namespace, but somewhat like how these are combined. For example, for this short example for CD and LD, the order of these indicators is not important here. But for other cases in the future, it possibly may be. So this somehow reminds me of the namespaces.
Carsten Bormann: Yeah, so I just gave an example that this doesn't need to be a single single character. I was just trying to avoid the terms 'CDE' and 'ADE' which seemed to be a red flag for Laurence. But we could do this by using longer names just to make sure we don't use up the alphabet here.
Vadim Goncharov: Probably what I'm thinking of is whether such indicator may have parameters.
Carsten Bormann: That's not—the syntax is very simple at the moment. It doesn't do that.
Vadim Goncharov: So do we forbid this for forever or not?
Carsten Bormann: Well, we have the catch-all which is the application extension. We can put—we can throw everything into an application extension. But I was trying to point out that encoding indicators probably make it more obvious that we're really talking about encoding here and not about changing the data.
Vadim Goncharov: Well, that's better to discuss on list, okay. Transfer to next speaker.
Carsten Bormann: Marco, are you in the queue? Rohan is in the queue. Sorry.
Rohan Mahy: Yeah, I was just going to—I was just going to say my comment from the mailing list earlier today about the encoding indicators for preferred is just that there should be a way that even if it's a mode, that if I have CBOR and I bring it into EDN, that I can figure out if it's—if it was encoded as preferred or not. So if that means that I get—that I always get encoding indicators when it's not preferred or something else. Yeah, I mean, those would be—like, that would be one reasonable way to solve that problem. If there's another way to solve that problem, I'm fine with it. I just think that's a—that's a useful thing for people who want to do diagnostics should be able to find out.
Carsten Bormann: Yeah, so my answer to this would be that we have text that discusses EDN as an output format for a diagnostic tool that looks at binary and tells you what—what's in there. And that says there is an expectation that there is at least one mode of the EDN tool that doesn't say anything about things that are preferred serialization but does use encoding indicators when it's not. And that is of course for diagnostic implementations, not for implementations that are just there to provide a text-based interface to CBOR that is being interchanged. So we could complement that by talking about the input side as well. So I was trying not to standardize the buttons that a user, an implementer, an operational user can press on an EDN implementation. I think Laurence's presentation—oh, hey Laurence—that we're going to miss today was really interesting because it's talking about buttons for data model subsets and and some serialization considerations. So we may have to have this buttons discussion at some point in time, but again, EDN was not meant to standardize those buttons. Marco, do you want to say something?
Marco Tiloca: Yes, hi. About where to define CRI and complementing what Christian just said in the chat, my preference is very much to keep the definition of CRI in this document, EDN literals. It feels just the appropriate document to me and the extension is being used for a while now in a number of working group documents in CORE and ACE. So it'd be good to have this shipped as something defined in the document. Eventually it becomes close to RFC before those that use the extension. So I would really prefer it to stay in this document. Thanks.
Carsten Bormann: Thanks. On Christian's point in the chat: the backtick discussion was not as short as it may seem. So I tried to define those with Joe and we came up with what's in the document right now. We looked at about 10 programming languages and I sent a message to the mailing list yesterday, I think, that lists those 10 languages and their raw string design because raw strings are now ubiquitous. I think the only language I still use that doesn't have raw strings is C. C++ has them, C doesn't have them. So we looked at those and came up with what we have as something that is really simple on one end, but that crosses all—all the checkboxes. So I think this is pretty good even though the discussion was happening off-list in not even a design team in the RFC 2418 sense. But yeah, I think we cannot do much better than that.
Vadim Goncharov: Brief question but please feel free to shoot it down if it turns out there's a good reason this doesn't work. But if I understand correctly where this backtick is coming from, then the idea was that if we use the backtick mechanism, then we can get rid of all the—all that escaping mess. Short of that 'h' and 'b64' are previously—are already defined for single quote. Is there any good reason not to say just we use the prefix just for backtick and then have a way-way easier time around the single or dual-pass discussion? That would simplify a whole lot of things that we've been spending quite some time discussing.
Carsten Bormann: The integrated parser has to manage those backticks, so it's not entirely trivial. But yes, it's a simplification.
Rohan Mahy: So I would kind of go the other way, which is that the parsing is faster for things that just—that only have the single tick. And so using the single tick for IP and DT, and even for CRI, I think is better and faster. And that the place where you would need backticks is if you want to do regular expressions or you wanted to include an entire language like ECMAScript or Lisp or the examples that were on the list. I don't think anybody is seriously proposing—I think somebody did think about proposing regular expressions as an actual EDN extension. I don't think anybody seriously proposed doing an entire Turing complete programming language inside of an extension yet. Maybe somebody will. But the single quotes work just fine for all of the currently proposed extensions.
Barry Leiba: Okay, I think that has to be the last word on this. We're just about out of time. So two things: one is Laurence, sorry we were going to allow time for your topic, but since you weren't on the call earlier, we just kept discussing the other things. So let's—we'll defer that and take it back to the mailing list and bring it back in two weeks if we still need on-list or on-call discussion. And on the BNF issue, I'm still not really seeing that we can call a consensus on it. So what I want to do is say my sense is that it will work either way. It's a question of how we—what it's optimized for. And that's the kind of issue that I think just sort of a vote-ish kind of like thing, even though we don't vote, is probably the best sort of approach because we just have to pick something here. So let's take it to the list. I will compose a message, but I propose that we just do sort of an up-down, which way do you prefer we go, and let's see what the count is. And then the chairs will make a judgment from there. Because, you know, otherwise we just have Carsten and Rohan going back and forth and not convincing each other. So let's see who else is convinced. I'll just say offhand, as a non-chair, I kind of side on Rohan's side, but that's just me and that's not as chair. So... everybody think that's an okay way to go about this? Carsten nod.
Carsten Bormann: I will never not to voting.
Barry Leiba: Yeah, I don't really want to do it that way, but I don't see that we have another option right now. And I think choosing is more important than which way we choose. We just need to pick an approach and move ahead. And what's in the document or what Rohan proposes are the two options.
Carsten Bormann: The choice is not as inconsequential as you are presenting it here. So there is some actual damage from doing this wrong. And so I'm—I will continue to make technical arguments why it's a good idea to have isolation.
Barry Leiba: And that's fine. I'm just looking for who has been convinced. That's really more what I'm trying—I'm not really thinking of it as a vote. I'm thinking of it as 'tell us which has Carsten or Rohan convinced you that this is the way to go.' And let's see what the rest of the participants say on the list to that. So we are out of time and it was productive use of the time. Thanks, everybody. And I'll see you all on the list and back here in two weeks.
Christian Amsüss: Thanks a bunch Marco for following the notes this time.
Marco Tiloca: Thank you.
Barry Leiba: Thanks. Bye.
Vadim Goncharov: I'm here to be in the skin of that application developer, and I'd say that yes, I want this backticks and other escaping—not escaping, to exactly to have ability to develop complex extension like a programming language. Oh, but nobody listening to me. Okay. Bye bye.