Session Date/Time: 08 Jul 2026 14:00
Paul Hoffman: ...another few minutes, but we will probably start, um, maybe a minute from now.
Barry Leiba: Works for me.
Barry Leiba: Vadim says in the chat that the MeetEcho link is blocked in Russia. Lovely.
Paul Hoffman: Well, that seems odd that it—since it never has been before, but, um...
Barry Leiba: Right.
Paul Hoffman: Yeah.
Barry Leiba: Well, these network blocks do change over time.
Paul Hoffman: Yeah.
Barry Leiba: IETF links seem an odd one to do, but...
Joe Hildebrand: The Russians don't want to have the EDN discussion. That's, you know.
Barry Leiba: There you go, yeah.
Joe Hildebrand: The KGB or whatever it is they really, you know, they're locking down on that.
Barry Leiba: All right, it's 01:00. Shall we get going?
Paul Hoffman: Yes, let's. So, good morning, good afternoon, good evening. This is the CBOR interim call. Um, this one will be a reasonably informal call in that, um, the, of course, one of the big things a lot of people want to hear about is what happened after—what did the chairs decide after the working group last call on EDN? Um, and the short answer is the three chairs have not come to agreement. Um, and, uh, we have something that I will present as a possible way forward, but this is not definitely what the chairs agree. Um, and Christian is not able to join us today for, um, family reasons. So, what I'm going to present, um, will be a proposal. It's not necessarily the proposal that's going to hit the working group. I hope that it is, um, because it's my proposal, or comes also from Andy. Um, um, and, uh, we will see how it goes. We promise to do everything on the list about this. Um, it was our hope that we would have done things on the list yesterday, but that didn't happen. So, given that, um, let me do upload my slides, um... Oh, no, I don't want to manage slides. Um, I want to present slides. And yet I'm not seeing the right button for presenting existing slides. Well, heck, here, let me just share them. Oh, here, no, we got it. Okay. Uh, so this, and again, I want to emphasize, this is something that the chairs have discussed offline, but have not come to agreement on. Um, but, and it's just two slides. Uh, the brief summary is that everyone wants an EDN document published. Um, we got no one saying do not publish an EDN document. And again, we're—these slides are descriptions of what we believe are rough consensus. Um, nearly everyone agreed with—there was a bunch of editorial improvements that were suggested with reorganizations, um, some naming changes and such, and we got a lot of people uh, supporting that. So, that's good. Um, this is where it gets odd. Three people said that the document was fine as it was, but then they also proposed removals and changes. So, it's very hard for us to determine what rough consensus is when we get, um, mixed views from the same person saying, "This is all fine, except for this and this and this." Um, even with those, the fourth bullet is the one that's most important here. There were some technical features, again, ignoring the—the uh, editorial, which many people sort of agreed on. Um, uh, some features had very strong opposing opinions where some people said, "This needs to be taken out," and some people said, "This needs to be left in." Um, and there was plenty of discussion, not just in the questions we asked, but about them. And so, what's pretty clear to us is that there is not working group consensus on how to move forward. That is, um, we can do it by consensus by exhaustion, we're not going to do that. Um, we uh, can uh, try this in other ways. But at the moment, it is—it is clear to us... Oh, and a red-tailed hawk just flew through my backyard. I guess that's auspicious of something.
Barry Leiba: That's an omen.
Paul Hoffman: It is an omen. I just wish we knew what the omen was. Maybe Carsten can clear this up. Um, but, uh, where—what we have right now is the lack of consensus. So, um, here is a possible next step, and again, I want to emphasize that the chairs do not have agreement on this yet. We hope to within a few days. Um, we would have liked to before now, but we don't. Um, Andy Newton, our Area Director, actually suggested something offline which, um, I think is a perfectly reasonable idea and I'll let Barry speak to it separately, but then we'll also pull Christian in, um, which is that there is a desire to have something that developers can use to validate and create CBOR. Um, we might create a single experimental RFC that has multiple EDNs in it. That is, that it would be an RFC, it would come from the working group, it would be experimental, but then, um, developers could look at things. So, this would, um, not have to have rough consensus on each of the features. Where we see the strong lack of rough consensus is not on the easy things like naming and editorial, but on saying a particular feature is um, in—in what we've—the one that we've been working on now, is good or bad or dangerous or whatever. So, um, for this proposed idea, um, it would—that is, an individual would say, "This is what I want as an EDN." And obviously, Carsten would be one of those individuals, but there are others, two other people have said that they would—they have their own views of what a good EDN is. Um, and the working group discussion would not be, "I like that feature, I don't like that feature." The working group discussion would be, um, "Is there anything technically wrong with this proposal?" And by technically, I mean either it does not specify everything that you can do in CBOR, or the specification is so wrong that an implementer who wanted to do that one of the EDNs would get it wrong. Um, we could take like six months on this. We can, you know, we're going to work on the idea over the coming weeks, assuming that Christian agrees, you know, that the working group chairs can come up with something. Um, but, uh, this would then end up again with a working group document. Um, I would probably be the editor, um, to throw things together. It would have introductory material saying why is this not a single one, what do we see as the obvious disadvantages of doing this, which is namely one would be better, um, explain the experimentalness of it, things like that. So, we would have a bunch of introduction, and then, um, each proposal would be its own appendix, and it would have its own naming, it would have its own, um, uh, uh, MIME types and such like that. We—we would be able to arrange all of that. And then let the developer community figure out what to do about this. So, um, I'm going to stop here. I see a few folks in the mic line. Um, I want just before we leave this discussion, please don't get hung up on the name. And in fact, uh, Carsten has some slides about naming, uh, for the next one, which would probably be appropriate for the whole document if we—if we go—if the working group goes this way. So, Joe, please.
Joe Hildebrand: Thanks. Uh, first off, I mostly don't care about the name that much. So, great. Uh, two, uh, I'm pretty deeply opposed to this potential approach, speaking as the developer community or part of the developer community. I don't want to implement all 12 of these, uh, not going to do it, and so you're not going to get any implementation experiments—experience from me on that. Um, if you can come up with one, I'll implement it, but if you have multiple, I'm not doing it.
Paul Hoffman: Uh, so quick question on that, because you are the target here. Um, if there are three or four, would you implement one of them?
Joe Hildebrand: No. I will implement...
Paul Hoffman: You would not implement any of them?
Joe Hildebrand: No, because it's going to change. It'd be wasted work.
Paul Hoffman: Okay, fair. Thank you. Does that make sense? I'm sorry, I'm not...
Joe Hildebrand: Yeah, yeah, no. Makes sense, yeah.
Paul Hoffman: ...trying to be difficult here. I'm just being pragmatic. I have a limited number of hours in the day, I'll implement one of these things. I've already implemented it three times, and it's changed enough each time that I've had to redo it. I'm—I'm not going to—I'm not going to go down that road again.
Paul Hoffman: So, if, you're—and—and again, I'm doing this sort of as the proponent of this, and I'm happy to hear um, disagreement. So, uh, you have a library, and someone says, "I want to use your library for that spec over there, which uses, you know, Appendix C or D."
Joe Hildebrand: Yes.
Paul Hoffman: And you would look at that and go, "Yes, I want to do that," or "I don't want to do that," but you would be, given that there are multiple appendices, you would say, "No, not until they have picked just one."
Joe Hildebrand: Exactly.
Paul Hoffman: Okay.
Joe Hildebrand: And I would, I would—that would be a hard, firm no. Um, luckily, I'm an open-source developer, and so I get to tell people no. That's my—my one superpower.
Paul Hoffman: Okay. Thanks, that's...
Joe Hildebrand: It keeps—it keeps my sanity.
Paul Hoffman: Yeah. And sorry, I interrupted you. If you had more to say, please go ahead.
Joe Hildebrand: I do. I have an alternate proposal.
Paul Hoffman: Great.
Joe Hildebrand: That just came to me, um, and it's sort of similar to what a couple of people have been saying, I think, a little bit. Which would be, what if we published a document that was the minimum subset? We took out everything that we could that was at all controversial.
Barry Leiba: So...
Joe Hildebrand: Sticking with, with a baseline.
Barry Leiba: ...that's what I have suggested.
Joe Hildebrand: Okay.
Barry Leiba: But what we see from the analysis of—it—Paul noted...
Paul Hoffman: Which by the way, I have not sent out the analysis yet because I was waiting on this, but we we we have collected all the stuff. But I'm sorry, Barry, go ahead.
Barry Leiba: That's fine. Um, so, Paul had said in his first slide that we—there are—it—in the call for, you know, "What's important to you?" there were people on one side of a particular item saying, "This can't get cut," and others saying, "This has to get cut."
Joe Hildebrand: Yeah.
Barry Leiba: And that's where we get the problem. If we could just—if we could have everybody say that the overarching thing is we have to publish, and if that means cutting something that I want in there, that's okay, if we get consensus on that, we can do what you suggest, Joe.
Joe Hildebrand: So, I'm willing to sign up for that point of view. I would rather have zero documents go out than this proposed document—than Paul's proposal. Um, and to that end, I'm willing to sacrifice any feature that I previously said was important or useful or required or anything.
Barry Leiba: Okay.
Joe Hildebrand: And I would ask others to sign up for that same point of view, particularly if a given feature could be added later in a backward-compatible way.
Barry Leiba: Okay. So, that's something we can float to the list and say, "If you said this is a critical thing that can't be removed, if we need to remove it in order to publish, will you accept that?" We'll float that...
Joe Hildebrand: And is it possible that that—that feature could be added in a later document, either an extension or as a revision to this document later.
Barry Leiba: Okay.
Paul Hoffman: Great, thanks. Did you have more to say on that?
Joe Hildebrand: No, that's my—that's my final say.
Paul Hoffman: Okay, thank you. Carsten?
Carsten Bormann: Hi, can you hear me?
Paul Hoffman: Yes, we can.
Carsten Bormann: Thank you. Um, yeah, so this was a pretty surprising... Yes, we can hear you. ...slide here. Um,
Paul Hoffman: Yes, this, and by the way, we totally admit this is surprising. It—in a better world, we would have sent this to the mailing list before now. So, we fully admit this is not what we wanted to do.
Carsten Bormann: Yeah, so, um, I think there are two interesting observations here. One is the—the perception of consensus that appears to be mostly by measuring the noise level. And, of course, there's lots of noise, uh, on the—the mailing list. Uh, and, um, it is probably hard to see that we have made significant progress in—in converging here. And what this proposal does is essentially taking away the—the uh, incentive to converge. Correct. Everybody can now do his pet thing again, and, um, there's—there's no thought at all to who actually has to use this stuff.
Paul Hoffman: That's not true. There—there is a thought there. Carsten, wait. Wait, I disagree that there was no thought. We recognize that this sort of sucks for many people and, as Joe pointed out, it very much sucks for him to the point where he would not do it, but saying there was no thought is not true.
Carsten Bormann: Okay, I wasn't there. So, uh, I can—I can only look at the results. Um, so, we we have about a dozen people who are actually using this stuff now in RFCs. And I think these people are getting ignored. And I'm not very happy about that. And I don't know why we are looking about the—the uh, squeaky wheels here, uh, instead of looking at the working group. And I'm going to stop at this point.
Paul Hoffman: Uh, actually, before you stop though, Carsten, um, how would you propose that we take in those people's use—the fact that they are using it and such, into our consideration differently than how we did it in the working group last call and the follow-up to the working group last call? How would you get us to be—I hear that you want those as a priority. How would you get us to make those a priority?
Carsten Bormann: Well, the the— I really like the the idea of sorting the various inputs by—by the structure of the document, um, and that that worked pretty well. We now have uh, responses, feedback that is pointing to a specific place, and that actually uh, aids my work as well because I can actually address these things. And I I have a slide that that looks at where we are with that at the moment. Um, so, uh, yeah, there is some text in there that that refers to um, things that are true before we actually do our our final convergence uh, here. So, we probably can get a better result uh, after processing the working group last call. We just haven't processed processed it yet. Um, so, um, how would we actually look at the—the people who are using this? Uh, well, not by making a proposal that uh, we take— we create a document that nobody can or will implement because it doesn't make sense, like Joe said. Uh, so I would rather keep the pressure up on convergence and uh, execute...
Paul Hoffman: That's not what I asked, Carsten. I I hear that you want that. Of course you want that, that's been clear for years, and that's anathema to many people in the working group. The specific question I asked is, you sounded unhappy that there are specs out there that are using some features here, and that we didn't listen to the fact that there were those specs. How would you, in the working group, as we are determining rough consensus, pay more attention to those? That's the specific question.
Carsten Bormann: Well, there have been responses from some of these people. Unfortunately, not from the majority, but at least for from some of these people, and um, well, they usually have been pretty short, uh, because the document currently does what those those spec writers want. And for for them, it's mostly Brownian motion, what's what's going on uh, right now. So, you—
Paul Hoffman: How can we collect that information better to—if you—again, I'm not—I'm I'm hearing you want it as a priority. I haven't heard from other people in the working group, but if you wanted it as a priority, how do we get that factual information to prioritize it?
Carsten Bormann: Well, we could ask people.
Paul Hoffman: Okay, well, yes, but I mean, how do we find the people and such? It sounds like you have a list of specs that need certain things. Can we pull that into the working group?
Carsten Bormann: I'd rather ask the the individual people. Of course, I also have RFCs out there that that use some of this. Um, so, uh, maybe I can make a list of of features, but I don't know uh, which features are actually at peril at the moment because I can't diagnose this from the from the current uh, status of of the response uh, document.
Paul Hoffman: Okay, great. I would, if if you want that as a priority, I would say, "Please do that," um, and bring to the bring—bring it as a separate item to the working group, not just in the discussion that you say, "Oh, but this one's needed by this." A separate list that says, "These folks are doing it this way," or just even in your own work, "I am doing it this way." I think that would be helpful to the working group.
Carsten Bormann: Okay, thank you.
Paul Hoffman: Thanks. Rohan?
Rohan Mahy: Hey, okay, so, um, you know, I, process-wise, I could go either way. I'm, like, I I kind of do like Joe's um, Joe's proposal, and I would also be sort of okay with doing the experimental thing as a way to figure out what people like, um, to have some concrete, filled-in thing, um, but I do agree, like, you know, it's—it's going to be implemented less, it's not going to be referencable by external standards-development bodies, etc., if it's like that. Um, my question to Carsten about, you know, "This is in—this is in internet drafts and RFCs," is, well, uh, you know, and as somebody who has—who's like the editor on on two documents that have a normative reference on EDN, how the hell did these get to be RFCs if they have a normative dependency on EDN and EDN isn't specified? Um, frankly, um, you know, if if this is just, "Well, we specified exactly what was in Appendix G," um, we could we could we could go and do corrections on that, and that would be pretty close to, I think, what um, what Joe described as a minimal set. We could even possibly, we might even find out from that corpus that we could throw out other features that people didn't like. Um, if not, if people have features there that they, you know, they assumed would be there, that are not in Appendix G, well, I kind of feel like, shame on them, you know, they should they should go and update their RFCs so that it corresponds to whatever we actually finish doing.
Carsten Bormann: So, if I can quickly answer the question. Yes, please. There are several ways to uh, work around a tardy working group. And, one approach is to simply copy as much of the spec into the the target document as is needed to make this work. And that is, of course, even worse than the proposal we are looking at. Except that, well, people pretty much seem to select the same things here. So, for instance, COSE uh, defined uh, a form of deterministic encoding that it needed for signing inputs, before that actually was written up uh, in a in a reasonable way and in 8949, um, and we have been able to to work with that. That was not a problem. And the other observation, of course, is that we are using to we're using this uh, for examples, and these examples can be declared informative, and where that is a way we may not need to copy things. But, yeah, if things are really needed, you just copy the text. And uh, that's not a situation you want to be in too long.
Paul Hoffman: That sounds good, and again, Carsten, this does put pressure on you to list all of these things that you have seen, um, not in a rush, obviously, but I think that would be super useful for the working group to actually have that as a standalone list.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to uh, speak in favor of Joe's proposal, that we find a minimum set and publish that, um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in uh, really disagrees, um, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna uh, to think about ways to actually make the working group list more more efficient beyond just just uh, putting out uh, strong words. Um, and uh, one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions uh, removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if you're ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Great. And—and—and having a clear way to do that would be lovely.
Joe Hildebrand: It would be great to have it to have like, stuff, uh, ironed out, but I don't care, frankly, if we don't have a defined extensibility path because as long as it will break an older tool, that's all we need.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that to the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up, but I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal.
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again... Go ahead. ...I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later later. So, yeah, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, there are some 150 documents referencing CBOR stuff, so that will take a couple of minutes.
Paul Hoffman: Well, except that if they are referencing CBOR and they're using the—the, you know, just the diagnostic notation, we don't need to worry about those. Uh, the list of ones that have used extensions are the ones that are relevant to the EDN document and whatever however else we work move forwards. Laurence?
Laurence Lundblade: Yeah, I mostly want to, uh, speak in favor of Joe's proposal that we find a minimum set and publish that. Um, that seemed a sensible thing to do to me. Um, I also want to, I just get a little bit of feeling about how consensus is. I mean, consensus doesn't mean everybody agrees, so you can have, we can have consensus on something where somebody in, uh, really disagrees, if it's just, if it's, you know, in the in the rough and, you know, that person that's in the rough could be Carsten. So, it's, um...
Paul Hoffman: So, right, we we were talking rough consensus, and again, I apologize for not sending out the the new, um, the the, uh, annotated version again, uh, simply because we wanted to send out the annotated version with a way forwards. And now, I think we have an additional way forwards. I mean, I'm hearing multiple people here supporting Joe's idea of, um, after—you know, have Carsten do a reorganization based on the editorial changes that everyone agreed on, or not everyone, but for which there was strong consensus, um, on the reorganizations and such like that, um, and then go through and say what needs to be removed, you know, which which new things need to be removed. Um, that sounds like, uh, that there are plenty of people here who are interested in this as well.
Laurence Lundblade: Um, yeah, I mean, and then, then the way also seems to be the way for consensus also maybe going chunk by chunk, like feature by feature. Is there consensus on this feature? Is there a feature consensus on that feature? You know, what's the status on this feature and that feature? So, if we come up with a kind of a canonical list of features, um, and really try to be, uh, I don't know, clear-minded, concise about it, not get wrapped up in, like, well, this depends on this, and this document said that, blah, blah, blah, blah, just just get the clear list of, like, 10 features, and just say we're only going to have 10 features, and just try to try to kind of bust through some of the consensus here without getting twisted up. Like, I I'm not that, you know, like Carsten's discussion like, well, some people are using it. Well, um, we've been working on this for forever. Uh, if some people are using it, using that, and people are talking about it in other working groups, I mean, that's, that should have been brought in here by the people that are proponents of those things. Um, we we can't that, now is not the time for that. It's, that was, that should have been thought through and brought here by whoever thinks that's important, they should have been brought here, um, months or years ago.
Barry Leiba: So, what I think you can expect to see in response to Joe's suggestion is that we will float to the mailing list the general idea that publishing the document is more important than any particular feature, and if we have to remove features that you need, will you accept that in order to get the document published? And do we have rough consensus on the concept? Then, we will go, "This is the list of features we think need to be removed." That will come next. And we'll get consensus that it's okay to remove those under the conditions that we just agreed on. And, of course, there can be pushback on any particular one of those features and discussion that may change that, and we may find that we do develop rough consensus to keep one of those features after that situation happens. We'll see where that goes. But that's what I think you can expect from that.
Paul Hoffman: Yeah, I think that that sounds right, and, um, again, Barry and Christian and I talked about this offline, and what Joe is suggesting actually aligns with what was the reason why the three of us didn't say this possible next step. So, I think we can that Barry and I can say that that's what will happen. I do want to go back to something you said, Laurence, which is if we can just get people to, you know, stick to the topic and such like that, um, I know that no one's going to want to hear this, but the chairs have tried this multiple times, and it's been just a freaking disaster. This working group refuses to not come up with long explanations of what's important, why what I'm doing is better than what you're suggesting, um, why this thing, you know, we should add this because I just thought about this, why we should do this. So, I am not, even though I believe we are going to go forwards with, you know, what what Joe suggested, you know, as Barry just said, but I do not believe this will necessarily succeed. This group has had a stunningly bad record of staying on topic and being specific. Um, Andy has, our AD, has made it really clear that this is not a permanent group, and that if we cannot start getting like, rough consensus on important documents, this is just going to get shut down. Um, and I want to really emphasize that of that if we go forwards on this, and the working group continues to do what it has done for years on this of, "Well, you don't agree with me, but you're obviously wrong," or, "You're not thinking of the computer science terminology," or whatever, we're—this will just get shut down, and we will have no document. And again, I want to emphasize the first point on this slide, which was everyone wanted an EDN document published. What I didn't say here was, "But people weren't acting like it." Carsten?
Carsten Bormann: Yeah, so, um, maybe we can um, use the time until Vienna to think about ways to actually make the working group list more more efficient beyond just just putting out strong words. Um, and one thing we haven't quite used as much as we could is the GitHub repository, so we can put stuff there to offload things. Of course, in the end, the consensus finally needs to be on the mailing list, but all the technical details don't have to be there.
Paul Hoffman: Yes, they do. Uh, you and I completely disagree on this, and, um, using a GitHub repo to make technical decisions removes the decision-making process from a large number of people in the working group. Um, there are working groups that do it that way, and they generally end up having a lot of attrition. So, that ain't going to happen here. However, I do appreciate your prop— Yeah, sorry, go ahead, Barry.
Barry Leiba: I'll also note that having an extended discussion on the Git repository is not any better than having it on the mailing list from the point of view of making progress.
Paul Hoffman: And it's worse in the sense that it is limited number of the participants. So, but Carsten, I do appreciate that you want to think about um, how the procedures for, how can we make this um, more how can we use the list better to do the, "What do we eliminate?" Um, one thing that I feel, and again, looking at the second bullet here, uh, that would be useful is if you, Carsten, can do a pass, and I will get out the the summarized list, of just purely editorial changes: rearrangements and such like that, and do that in— I was going to say in the GitHub repo. If you can do a clean pull request that is a diff from the current draft to the revised one, and then use one of the tools to put out, you know, a new version so people can see it, that will certainly help the discussion of which specific things are we talking about. Um, and then there is also the discussion which I'm seeing over in the chat, uh, which I'm not paying that much attention to, but, uh, the ABNF. Changes to the ABNF are technical changes. They are not editorial changes. How do we deal with that? And I think that has to be a working group discussion. Nikolai, please.
Mikolai Gütschow: Yeah, hi. I just wanted to say that I'm a bit surprised with like, as a lot of us, I guess, with this proposal that you proposed. And—
Paul Hoffman: Yeah, yeah, yeah, absolutely. This—this—this was—this was not meant to be a surprise, but it was.
Mikolai Gütschow: Yes, and I'm also a bit surprised that you um, kind of uh, described the working group as you do right now, uh, after we we had the um, in my view, much more um, kind of uh, clean way of discussing, or not discussing, but kind of uh, listing the bullet points, and then agreeing or not agreeing. And I think the working group actually did a pretty good job in organizing... Okay. ...thank you. I—I—I appreciate hearing that. That's not the way it felt in my body, but I am glad to hear that you felt that. I mean, for for some time at least, it was kind of quiet on the list, and it was focusing on the points that uh, that were raised and then agreements to those points. So, so I was really expecting, and uh, you said that you will send that, but I think that's the necessary next step to actually have the list, uh, the overview of what are actually the technical points that are still in discussion, because at least from my look at the uh, agreements on the list, it didn't look like there were so many of them. So, um, that's why for me it feels a bit surprising that that we seem to be at this uh, stage where everything is so complicated, um, if, in my opinion, or from from from my uh, look at the mailing list, uh, I felt that we were converging pretty pretty well in this last uh, few weeks.
Paul Hoffman: Great, and I would—I would like you to be correct. I definitely am happy to take Andy's advice, you know, our AD's advice, and ignore it if we can do a thing that will, in fact, help developers, you know, get this done correctly. That would be good. What we're not willing to do is grind on this forever. Um, but if this is a two-step process, first step being do all the editorial changes that folks agreed on, and Carsten can certainly do that, and then go through a simple list, that would be wonderful. Joe?
Joe Hildebrand: Hi. Uh, so number one, I think that uh, having Carsten's editorial changes in into a new rev of the document would be terribly helpful so that we have new section numbers to use as the structuring for the discussion. Um, next, I think it would be good to have a a pretty good consensus call on, "Do we agree that removing features is uh, worth it in order to publish a document at all?" Um, I think that one should be relatively crisp and easy to get agreement on, I hope.
Paul Hoffman: Do you agree that we could actually make that second decision before we have seen the—the editorial changes?
Joe Hildebrand: 100%. That can be done in parallel.
Paul Hoffman: Okay, because we we have weeks now before Carsten can actually publish the new document—the the revised document, where we can have exactly that discussion. I would like to have it. I I don't know what Barry feels, and we can't know what Christian feels, but I would like to have the—the Joe discussion first.
Joe Hildebrand: Yeah, that one feels like we could come to consensus on that, I hope.
Paul Hoffman: Great.
Joe Hildebrand: Um, and then the next thing I'd like to have a separate consensus call on, once we if we were to agree on that, would be what the rubric is for deciding what features go and which ones stay. And if we have a relatively crisp rubric like the one that I put in the chat, um, then—
Paul Hoffman: Which you will send to the list.
Joe Hildebrand: Yeah. Do you want me to send that toJoe Hildebrand: the list?
Paul Hoffman: Uh, why don't you give it a day until we have put something up? But I absolutely don't want this to be the working group chairs tell the list, "This is how we are going to make decisions." Um, that, we've done that in the past, and that has obviously failed if you look at the number of people who say, "Well, ignoring what the chairs asked, I'm going to comment this way anyways." Um, so, having the working group help decide that, even though that delays things a bit, I think might get us a better process.
Joe Hildebrand: Uh, that's fine. So, I'll, let me know when it's time to send that, um, but I think a consensus call on that that says something like what I said here, but, you know, like there are two people that agree that there's some valid technical point to removing something. Like, anything that we can remove, we get rid of. Like, let's just be aggressive on this so that we can pair this thing down and get it out the door, is my suggestion.
Paul Hoffman: Sounds good. Please, in—in the next day or two until the chairs get this out, please be thinking about your specific wordings and hop in as quickly as you can after we start the general discussion.
Joe Hildebrand: I'll do my best.
Paul Hoffman: And that's true for everybody, but since Joe, I'm going to call this the Joe proposal, um, because it's not the Andy proposal. Um,
Joe Hildebrand: It's the Barry proposal, though. He just didn't get a word in edgewise before I did.
Paul Hoffman: Yeah, no, but this is the Joe proposal. So, please, and—and again, I'm saying this to every Joe in the group. Please have an idea about how you feel we can make the decision on what to remove in a definitive way so that we don't have a discussion in two months saying, "Gosh, we're just grinding now," because grinding will mean zero documents published, and, again...
Joe Hildebrand: One thing— sorry, go ahead. I thought you were finished.
Paul Hoffman: Well, I just want to say, this first bullet's important: everyone wanted a document published, but we can't publish a document if the answer is we're going to grind on it for another year.
Joe Hildebrand: And so the attitude that I'm going to try and bring to the table is, it's okay to jettison a feature that I like if I can add it later, particularly if I can add it later. So, yep, it's okay to jettison any of my features, um, and, particularly if I can just write a doc that says, "Oh, here's an extension to it," in the same way that we've got extensions to ABNF that say, "Oh, this means, uh, that it's case-sensitive," right? So, that's an extension to ABNF that, you know, the older tools didn't support, the newer tools do, and if your ABNF uses it, you have to use a newer tool. No big deal.
Paul Hoffman: Great. And—and—and having a clear way to do that would be lovely.
Joe Hildebrand: It would be great to have— to have like, stuff, uh, ironed out, but I don't care, frankly, if we don't have a defined extensibility path because as long as it will break an older tool, that's all we need.
Paul Hoffman: Yep. Yep. Excellent. So, uh, and Carsten, you are last on this. I accepted your slides for the naming. Let's not do the naming discussion today. I think that's reasonable to do on the list, but why don't you finish out this discussion, and then we can have Laurence give a update on the serialization document.
Carsten Bormann: Yeah, quickly, um, you cut me off when I was trying to say what we could do to uh, take load off the the mailing list. Um, the other thing is that we need to document our current thinking. And, uh, of course, it's— it's really hard to find out what somebody thinks if if uh, messages went back and forth for a while. Um, so, uh, we need a way to to have uh, little snippets that that, uh, actually are useful for people to find out what other people want. So, right now, I have absolutely no idea what other people want because most of them, uh, have been sacrificed on the altar of of consensus, which I think is a good thing. Uh, so now with the pressure a little bit taken off, uh, they will come back and say, "Oh, I want this removed, and that removed," and so on. Um, so, let's— let's use those uh, documents. And, um, the the other, um, observation is that, um, it's really hard to work on something like CBOR because there are very, very, very different usage environments. And nobody in this working group actually knows even half of what CBOR is actually being used for. So, we have to be able to actually converge our perspectives and then come up with uh, something that that takes the various perspectives into account. Um, yeah, but, um, I'll stop now so Laurence can— can do his uh, thing.
Paul Hoffman: By "stop", I mean we take it to the list, of course.
Carsten Bormann: Yes. Um, one, uh, comment, maybe: bike sheds are best discussed in interims and— and face-to-face meetings. So, that's why I wrote those slides.
Paul Hoffman: I agree, and— and if— if— if this meeting had gone the way I thought it was, which is everyone goes like, "Oh, yeah, Andy's idea sounds fine, we'll discuss that later," we would have had time to bike shed this, and um, I liked your first four slides on the bike shed. Um, we can either do that in the face-to-face, we can do some of it online, but I agree that bike shedding on the list, uh, tends to uh, become exponential, not sub-exponential. Um, fortunately, if we're just doing naming, that's— that's a thing that we can even do late in the process. Um, so, yes, so please— please don't throw away your slides, but we'll figure out a time to do that bike shedding.
Carsten Bormann: Thank you.
Paul Hoffman: Yep. Okay, well, thank you everyone. Uh, this was uh, not what I expected and I think much better than I expected, and um, we'll actually have uh, some fairly positive effects on the list, um, and again, getting to the document actually being published without the solution being, "Well, let's grind slowly on it." Um, Laurence, do you want to give us an update on the— what's going on with serialization and where you think our next steps are?
Laurence Lundblade: Sure. Uh, there we go. Um, so, uh, I don't have slides, um, as you saw on the list, uh, draft 07 was published. Um, it had the uh, the new things were the sample source code for encoding floats for uh, Preferred plus and Deterministic. Um, um, I— I replaced the CDDL control operators, uh, .prefP and .dtrm with a .cbor. Um, actually, I would like comments on that, um, that's not something I feel um, as confident on as other things. Um, there's uh, some uh, rework on the— a lot of the explanatory text about general and special serialization. Some of the text moved around. Um, and also there's a shorter text on uh, where to use Preferred plus, uh, and wordy improvements on the intro. Um, so, uh, basically, the— I consider the document in quite good shape and largely ready for working group last call. Um, um, uh, you know, one of the reasons I went and published the 07 was, um, just because people tend to look at the draft rather than the PRs, um, and it had been a long time since anything was published. So, I— I went and pushed that out. Um, uh, the only issues open in GitHub are the um, security considerations, um, and uh, a couple days ago, Rohan provided uh, that, and um, um, uh, we've— I've edited, and um, there's a PR there that Rohan and I agree on. So, um, uh, that's— I basically consider that security considerations considerations issue solved. It's just a matter of um, a little more time for review, and then merging it and publishing to get that done. Um, and I think it's not anything difficult or controversial or anything like that. Um, certainly nothing that would be um, delay publishing the— the document. Um, um, the— the— the other discussion that I um, have out there is uh, um, some things about byte string wrapping related to the Bundle Protocol, um, I might like— might propose adding a little bit more text, um, but I don't think any of that is uh, critical to um, working group last call. Um, and uh, I've just one last comment is, um, I'm kind of— the Bundle Protocol, I mean, I I've said it on the list. I think the Bundle Protocol really probably shouldn't have been published as is. It's got some fairly large problems with the way it handles CRCs and hashing and— and my opinion. I'm— so, I'm trying— we're trying to work on that on the list. But I probably will contact the authors, and, you know, as a— an author of a CBOR library trying to support bundle, it's like that— that's sort of unimplementable, really. It's kind of ugly. But that's not for discussion now. Um, uh, that's just a notice. Uh, Rohan?
Rohan Mahy: Uh, yeah, I'd say like— I'd say any mention that we make of bundle should be really minimal in my opinion. So, if it's— if it's just like, "Here's an example of a protocol that tried to do something different, it didn't really work. Here's the reference." I think, you know, one or two sentences max is plenty for— for that topic.
Laurence Lundblade: Yeah, yeah, I— I agree. I mean, even if we don't mention it at all, that's fine. I don't...
Paul Hoffman: So, Laurence, uh, when you said there's a couple of open issues, do you mean two, five, 10?
Laurence Lundblade: Uh, zero. Did I— did I say a couple of open issues? No, I think I said—
Paul Hoffman: I thought you did. I— I am happy to be wrong. So, given that, um, although you do have to, you know, you— you know, the security consideration is an open issue just in the sense that we don't have it in the draft.
Laurence Lundblade: Right, that's all.
Paul Hoffman: Um, would you publish a new draft, um, when the window opens, uh, in a week and a half? Um, and we will discuss it during the face-to-face meeting, but then are you— I don't like opening working group last calls with known, like, significant open issues, but if you feel that any open issue is not significant or easy to do, would you be comfortable with us starting a working group last call, essentially during Vienna, and, uh, two weeks later we would know?
Laurence Lundblade: Yes.
Barry Leiba: And I— I would like to see the— the text of the proposed security considerations just posted to the list in an email message before— as soon as possible before the draft, so we have—
Paul Hoffman: Yeah, if you can— agree. If you can do that and then, you know, if— if no one disagrees or whatever, take whatever, but then do a new draft right at the beginning of of the meeting, uh, we talk about it in our meeting on Thursday, I believe we are meeting, but—
Laurence Leiba: Yes, Thursday.
Paul Hoffman: ...my calendar— okay, on Thursday, and then with the intention being that we will open up working group last call like right then, and— and have it not be long, you know, have it be a normal two-week working group last call, uh, that would be great, uh, much appreciated.
Laurence Lundblade: Yeah, so let me recap. preferred— Bundle Protocol is not a— an urgent issue for the serialization draft. That's just think of that as a discussion of uh, something else, um...
Paul Hoffman: What might go wrong if without a serialization draft? Yes.
Laurence Lundblade: I mean, it's tangentially related, it's not critical to that, um. Uh, yes, I will publish— I will— I will put the security considerations on the mailing list in the, you know, by the end of the day, um, and as soon as the window opens for publishing a draft, I'll publish a new draft with the security considerations, and there might be a few little editorial tweaks in there as well, um, but nothing large, and then uh, with the publication of that draft, the next draft, with the security considerations, uh, I believe we are ready for working group last call, and that can proceed uh, right away.
Paul Hoffman: Okay, well, I won't do it right as you have published it. I will wait till after we have our face-to-face meeting, which is four days after the window opens, but then it's my intention to start that immediately after that.
Laurence Lundblade: Okay.
Paul Hoffman: Yeah. Great, thank you. Um, looking forward to that on the list. Um, so that's it for today, we have almost hit the end of the hour. We have the face-to-face meeting coming up, um, uh, Rohan, did you want to jump in on something?
Rohan Mahy: Um, I just wanted to report on the— the results of of my search during this meeting of—
Paul Hoffman: No, no, no, let's not— let's not do that.
Rohan Mahy: Okay, let's not do that. Sorry.
Paul Hoffman: The fact that you said an AI search, my attitude is, um, let's not argue about that. Um, so, we've got the meeting in uh, approximately in two weeks from tomorrow. Um, and—
Barry Leiba: Just take a quick look at the uh, does— do we have any agenda bashing? I posted the agenda in the notes. Um, do we have any agenda bashing early?
Paul Hoffman: I will ask for that on the list. I think I think given how much uh, changes have happened in the last 53 minutes, uh, the agenda is going to have to change significantly even though our amount of time will not change.
Barry Leiba: Yeah, yeah, you're right.
Paul Hoffman: Yeah.
Barry Leiba: And then the only other thing is, um, uh, is there any— does everybody agree that we keep the biweekly cadence of of meetings and the dates are in the— the list? Um.
Paul Hoffman: And so that would be, the first one would be two weeks or slightly less than two weeks after our Vienna meeting.
Barry Leiba: Right, and it's the usual thing. If we don't have anything in particular that we need to talk about, then we'll cancel them, but this gets it on everybody's calendar.
Paul Hoffman: I believe we should go for the two weeks immediately after because that would be approx— that would be very close to the end of working group last call for serialization, and it will be in the middle of we are doing— we are deciding how the working group is going to proceed on— on EDN. Um, and so I think that at least for that one, and I see Ira saying let's keep the biweekly cadence, um, I think that we've done reasonably well with it. Some weeks have seemed like not much has happened, um, and this week shows that that in fact these are very good.
Barry Leiba: Absolutely.
Paul Hoffman: Okay, so please stay active on the working group list, you know, uh, between now and then, and um, uh, we will, you know, we will have a— unfortunately, a tight agenda. We when we chose an hour, we thought that there wasn't going to be that much to do, but there is. Um, and so, on EDN, Carsten, please get your editorial pen out, um, if you have time. Hopefully, you have time in the next almost uh, week and a half before the um, publication deadline is open. Uh, the chairs— uh, Carsten, is that possible? Yes?
Carsten Bormann: I just wanted to say, I have about a week. Um, so, I'll merge the current PRs and— and do the big editorial thing that was promised and then we can resubmit on on Sunday. I think Sunday.
Paul Hoffman: Very good. As long as— as long as those PRs are only on the editorial stuff, not on any of the, um, "Please add this, please remove this" part. That would be great.
Carsten Bormann: I think so.
Paul Hoffman: Okay.
Carsten Bormann: Yep.
Paul Hoffman: Well, let me— let me be more definitive. If you screw up on that and you start doing technical changes in there, it's going to make it harder for us to come to rough consensus. So, anything you do that makes it harder for us to come to rough consensus is not going to be appreciated by anyone. So, do— do try to minimize to editorial. Um, we will have that. We will have discussion on the list of, um, how to move forwards. Uh, I will commit for the chairs that we will have something to you by Friday, if not tomorrow, um, so that we can have the— the Joe discussion, as I will humorously refer to it now, um, and I just want to say thank you for folks disagreeing with what we suggested. Um, I I the the way that the IETF works best is when we actually hear as many opinions that are lightly held, but with good direction, um, as compared to, "I need this from you, or I'm going to scream and cry unless you do this." Um, I really appreciate, Joe, you stepping up quickly on that, and I think that's a good way forwards. If it fails, we can try something else, but there is a real— I think that there from what other people have said, there is a good chance that, um, this could succeed and that we will we will in fact get an EDN out, and then we'll just have to think about extensions later. Uh, Barry, anything last before we shut down?
Barry Leiba: No, that's all from me. I think we're good. So, we'll see you all in Vienna on uh— well, we'll see you before then, but we'll, uh, Thursday is our meeting.
Paul Hoffman: Yep. Okay, very good. And— and— and like I say, the chairs— you will see stuff from the chairs, not just verbally and here. You will see something from us very soon.
Barry Leiba: Yep.
Paul Hoffman: Okay, thanks very much.
Barry Leiba: Okay, bye everybody. Thanks for coming.
Mikolai Gütschow: Bye-bye.