Session Date/Time: 29 Apr 2026 14:00
Marco Tiloca: Hi everyone.
Christian Amsüss: Hi Marco. So, let's wait a couple minutes to see if we get others. It looks like we have some pretty light attendance today. Christian, when can you start the meeting? I'm doing a little multitasking on this end, so I'll be in full attention in about five minutes. Oh.
Christian Amsüss: If it works now, yes.
Christian Amsüss: It does. I can hear you.
Christian Amsüss: Okay, then I can start the meeting and we'll switch roles in a bit because of... like I might at any time get distracted. So, if no one... No. Okay, let's get this... let's get this started. Hello everyone. This is an interim meeting of the CBOR working group. You all are very familiar, so I expect that you know how this works, that the note well applies at other... the IETF rules apply, etc. We have two things that we'd like to work on today. One is EDN diagnostic notation where Carsten has prepared slides, and then Laurence has proposed slides to talk about the serialization. So, we'll try to fit both into the agenda today. Any last-minute comments on the sequence in which we run things today, or things that we should make sure not to miss?
Carsten Bormann: Yeah, we didn't say how much time we have for the two slides. And like last meeting, I would prefer we had enough time to talk about Laurence's slide. So, let's try to time-box the EDN discussion.
Christian Amsüss: Yeah. We have... we have an hour in total. So, we... at the current agenda, we have 40 minutes for EDN, as I understand your comment slash partial implementations thereof. And that leaves us 20 minutes for Laurence's slides and Laurence's presentation. Does this work for both of you?
Laurence Lundblade: That works for me.
Carsten Bormann: Okay, so we have a nice message from Michael and yes, everybody... not everybody, or many people got some security problems due to the backticks in the... if you scroll back in the chat, you can see the exact error code that Marco got. Okay, so we're going to talk for 37 minutes about EDN literals and 20 minutes about partial implementations. So, the question is the same I had on the slides of the last two interims. Now, we did have some more discussion and some more exchange of text fragments. So, if you've paid attention, there is a -23 out there that combines all the current open pull requests. So, we have a document that everybody can look at if they want. And I would like to discuss five items here: the PRs that essentially we have closed and we just need to be sure that we all agree on that; the issues that seem to have a disposition that has been discussed but maybe not completely agreed, so some of these issues are still open and maybe can be... 23 includes both merged and open PRs. We have one PR that could be in the previous list, but that's interesting because it could be moved to the EDN wiki. We have pointers on test vector projects, so I had completely forgotten about Joe's EDN test vector, so that was a really good thing to point out on the mailing list that we have that too. So, I submitted a PR to that today to update it. And finally, there is essentially one PR we might want to confirm in this meeting, maybe we confirm it on the mailing list, but we at least want to have a temperature reading during this meeting. So, this is what I want to cover. So, let's quickly go through the PRs that have recently been closed and the issues behind that. So, number 102 changes the check of the... the argument for the simple value from a semantic check to a syntactic check because it's so easy to do that in ABNF. And so there is some text still in the document that talks about simple open parenthesis 0x14, and that has to be fixed. So, there's a new issue 103... we'll do this in the next 24 hours or 48 hours. Then, yeah, so, Christian, what... this is a nice example for an idiom. So, we now all understand the idiom of how to write a dotted quad in ABNF, so we can freely use that even though it's really, yeah, I don't know.
Christian Amsüss: I didn't want to interrupt this. Just pointing out that this... we... we know, but not every user will know. But anyway, it works. I'm fine with that. Let's not get distracted.
Carsten Bormann: Good. 101 is absolutely trivial. It's editorial but it touches the ABNF, so it's worth pointing out. There was a pretty badly named ABNF rule and there was a comment that this... there is a better name for that, and 101 fixes that. So, this has been put in, tested, and then after a while merged. Number 95... I have forgotten which one this was, but we have this cluster 87, 91, 95, which is essentially revolving around the question: which of the extension identifiers are mandatory to implement? And I have another slide for that. So, there is a proposal in the text that is not yet fully agreed from my point of view, but we also haven't heard disagreement. Issue 93 and the two PRs 94 and 96 responded to the observation that the current document does not say what NaN is.
Christian Amsüss: I just wanted to... finish your thought on what you were going to say about 93, 94, 96, and then I'll... and then I'll...
Carsten Bormann: Go ahead.
Christian Amsüss: Okay. So, we do have something a little bit weird with... now that we've defined, like, put some text about what to do with NaNs in this document. There's valid CBOR that we can't express in EDN without extensions. So, I don't think that we need a... we need it to be generally used, but I do think we need a float or a NaN app extension that allows us to at least express something that we discovered in CBOR when converting from CBOR into EDN. And we can handle this... like, I'm open to how we want to handle this. I'm just pointing out that being able to... you know, having legal CBOR that you can't express in EDN is... that doesn't feel right to me.
Carsten Bormann: Yeah, I don't disagree. So, this is not... has not been left out for a technical reason. In the Batch 1 document, there is a definition of at least one way to solve this. This happens to be the way that Joe and I have been using in the CBOR test vector project. So, it's reasonably well-tested, I would say. But of course, it can be done in a thousand ways. So, my old NaN proposal is still out there. Joe didn't like that, so we didn't pursue that. Again, it's something that can be done in a thousand ways. We have one that is at least implemented by two implementations. So, I have a slight preference to stay there, even though I like my own way of doing it much better. So, the working group last call result could be we want to fix this now. In that case, it's trivial because we know how to do that. Or we could have no special observation in the working group last call and we don't fix it and wait for Batch 1. Okay, anything else about 93, 94, 96? So, what 96 does is it shows how to combine NaN, the NaN label with an encoding indicator. And it shows that for other floating-point values as well. So, it's almost a test vector, but it really illustrates how encoding indicators work. And then finally, the MTI discussion. I have another slide about that, so I move to that in a minute.
Carsten Bormann: Okay, so there are five issues that we haven't really had a major discussion on. Two of these are issues that we don't have to solve now: 90 and 86. 86 is what we just talked about, the float thing and another thing, the same thing, and it seemed that both require some more discussion, so my tentative conclusion or confusion was to postpone those to Batch number 1. And 90 is interesting because it was an app extension identifier proposal that actually would use the other extension point of EDN, the encoding indicators. We don't have a full design on this, but yeah, it's probably not particularly hard to do that, but I would love us to have a month or so more than we have for the other things. So, that's 86 and 90. Вадим just mentioned 88 in the chat. Of course, we can generate additional scaffolding like the with-extension that I just invented an hour ago. But I think hash works as it is defined now. And yeah, now it turns into a discussion of whether we should simply write this up or maybe should wait. We can wait eternally until we have that. We can invent other stuff like with-extension to make it more difficult to use. I think hash, the way it is defined now, is the way to do things. And the observation that hash relies on an IANA registry for its semantic definition, that's of course interesting, but yeah, that's what you get in an extensible environment. So, since we want crypto-agility, I think we have to endure the fact that you will have things in there that are extended automatically using the IANA registry. Okay, and then we have number 99, which was the question: should we include an artificial limitation on the number of backticks in a raw string? And I have made my point why I think this is not a good idea. It is a point that has a little bit to do with my age because I was there when SGML was completed, and SGML had this elaborate system of artificial limitations, and one of the great things that the XML people did when they got rid of complexity in SGML was throwing all those artificial limitations overboard. So, XML does not have any artificial limitations at all. And that seemed to work. So, I'd like to hear who thinks that we should introduce artificial limitations in EDN. We are not introducing them in CBOR, but should we do something in EDN that makes one of the expressive capabilities subject to an artificial limitation?
Christian Amsüss: I just want to... I think it... your language might not be clear to everybody else what that means. But what I proposed in 99 was to have an upper limit for the total number of backticks. So, you know, 16 or 8 in a row or something like that. Hopefully that makes it clear. I think that having the ability to implement EDN in, for example, certain code editor environments, you know, reasonably be able to implement a regular expression that works for most EDN, like, those would be a couple of reasons why we might want to have such limitations.
Carsten Bormann: Yeah, I think it's pretty interesting to look at the specific example because artificial limitations probably make more sense in a constrained environment than in the capable environments that EDN is designed for. But also in this specific case, it's not limiting something like nesting depth of data structures or structural complexity, but it limits the size of a counter unit. And even in the constrained environment, we can use 32-bit counters. So, there should be no reason at all for such an artificial limitation. Yeah, we're seeing some comments in the chat and I'm sticking with my "who else wants this?" question. We don't have to close this issue in half an hour, but maybe we should try to think about this a little bit more and then close it soon. Okay, there is a PR from Rohan that proposes to make integrated single-pass BNF a default. Now, what is a default here? So, the document supplies BNF that can be used by an implementation, and implementations will use BNF or ABNF in different ways and we don't have to sit down and make any restrictions on how an implementation is supposed to use this. So, I think it would be a good idea to document a few choices here. So, for instance, if you use integrated parsers, how can you integrate this into the... how can you integrate the various pieces of ABNF that are available in the document? But I don't think we want to put those into the specification. This is exactly what wikis are good for, and we have a EDN wiki, so we might as well use that. So, the EDN wiki hasn't been touched for about two years, but yeah, we can always start doing that again. And if we have useful text explaining integrated versus isolated BNF, then we can put that there. So, that would be my proposal on how to deal with PR number 92. As I mentioned at the start, we have now rediscovered Joe's test vector... EDN test vector project. So, those test vectors are from 2025 and we have two PRs that we have since merged, 77 and 102, that change those test vectors. So, 102 I just mentioned about, we can no longer use a hexadecimal number for a simple value. So, those test cases just move from success to failure. And we have discussed more than a year ago PR 77, which reduces the number of variations that we allow in single-quoted strings. Now, with double-quoted strings, we are bound by our JSON compatibility, so we are never going to touch the double-quoted strings. The complexity that's in there is forced on us by the JSON compatibility. But we don't have to be JSON compatible on single-quoted strings. There is a disadvantage to doing something different here because the copy-paste capability is a little bit restricted by that. But then changing double quotes in a single quotes also hurts your copy-paste capability. So, I think the damage is not so large. The advantage of course is that those literal syntaxes that... those extension syntaxes that are ASCII-based are much easier to handle in an integrated parser. So, that's why it's... this was decided to be a good idea or... and that was more than a year ago, but the test vector set in that repository hasn't been touched for a while so it doesn't reflect PR 77 yet. So, I submitted a PR today. Let's see whether and when Joe finds time to look at that. There is one test in there that didn't have a clear resolution from PR number 77. So, it's marked as "overtaken by events". But we probably want to discuss whether we want to replace it by one or more tests that actually work again with PR 77. The CBOR test vectors are interesting because they are written in EDN. So, while the objective here isn't to cover all of EDN, the objective is to cover all of CBOR. We still have a lot of useful EDN in there, so it's a useful additional set of test vectors that people can use, but it's not going to be our main test vector repository. Any questions about that? Comments? Rohan?
Rohan Mahy: Mike Richardson suggested moving the wiki to the CBOR IETF wiki, the working group wiki.
Carsten Bormann: There will be a pointer from there. So, this is not the first wiki I'm setting up. It's generally too high-threshold to work... to do actual technical work in the IETF wiki. So, in all those cases we have just fanned out the wiki to a different place and well, today that's likely to be GitHub. Maybe tomorrow it's going to be Codeberg. I don't know, we can find that out. But most people know how to use a GitHub wiki at this point in time. So, the really important thing is that the IETF wiki is updated with pointers to all the wikis that are useful and some description what these are useful for. So, that's definitely something that's on my to-do list. Marco will remember that I have a similar to-do list for the CORE working group. Yes, it needs to be done. I completely agree with that. Good. Go ahead.
Christian Amsüss: So, I wanted to go back to the discussion about the single-pass BNF and just propose what seemed like a reasonable consequence of the... of the two models. So, we've had some discussion on the list about whether we provide, you know, comment syntax for things that are inside backtick-delimited strings. So, I'm just going to kind of suggest that if you have something in backquotes, it's very likely that whatever is inside there is going to have kind of pretty arbitrary syntax because the whole point of it was to avoid quoting hell. And so this feels like a natural fit for a two-pass BNF parser, or you know, any kind of two-pass parser where, you know, we parse... we have a BNF that describes... stuff... of course you can't just implement it only with BNF, but you have the thing that is on the outside of the backticks defined in the ABNF for EDN and then whatever is inside you would define separately. That feels like a natural fit. Whereas for single-quoted and double-quoted strings, what we already have is straightforward enough that it's pretty easy for us to just do this in the single-pass BNF. And basically what we provide is the hex digits in H, the base64 in B64, the date-time in DT, and the IP address with optional prefix in IP. So, this feels like a pretty clean split to me. I'm just curious if other people think this is... if this feels right, because this could... this has the potential for eliminating this sort of one-pass, two-pass discussion by just saying we do one-pass for anything in single-quote and double-quoted strings, we do two-pass for anything inside a backtick, and we're done.
Carsten Bormann: Well, yeah, so you propose to tell the implementation you have to do this.
Christian Amsüss: No, I think we have... let's say a canonical ABNF that says, "Here is a description of... here is a description of this protocol and it ends and starts here." And as with most other protocols, you know, if you go and figure out a way to go do this somewhere else, in some other way, that's fine. And we can put on the wiki if somebody really wants to do two-pass for H, B64, IP, and DT they can, but like it's pretty straightforward to have an integrated BNF for those.
Carsten Bormann: Yes, so what do you want the draft to say?
Christian Amsüss: I want it to define what is effectively a single-pass BNF for H, B64, IP, and DT. Say that these extensions are inside of single-quoted strings. Say that things which are backtick-encoded, that you parse the contents with a second... with an additional parser pass as a... or say that it is that we do not provide a single-pass way to parse those things. And then for CRI, we either define a separate pass for CRI, or we define a CRI BNF that does not allow a single quote as one of the sub-delimiters.
Carsten Bormann: Yeah, right now we have those backtick integrated parsers in the document. So, you would propose to remove them because they are kind of trivial.
Christian Amsüss: I would propose to move out to a wiki the two-pass H, B64, IP, and DT. And if... and then based on what people decided to do with CRI, if they wanted CRI to not include single ticks, then we would move that out.
Carsten Bormann: So, we have learned that in this working group we have two different approaches for doing this: the integrated one and the isolated one. We have learned that we both have very good arguments for why we want our implementation to be that way. And you now propose that your way of implementing things is the only one we should have.
Christian Amsüss: No.
Carsten Bormann: That is a bit of a regression.
Christian Amsüss: Because the explanation why we needed this was somebody might define an extension that's super complicated and would be really hard to put in a single-pass BNF and we would be making it hard for... well, no, that's what in the last interim meeting the specific argument made was that it would be more difficult for app extension writers, for people who wanted to write new app extensions.
Carsten Bormann: That was the point, yes.
Christian Amsüss: And they would be free to go do so with multiple backticks. They can go put whatever they want inside of the backticks and we're done.
Christian Amsüss: So, just for clarification to understand, is the proposal to... to just limit other extensions to use backticks and not use single quotes at all? Or is it just...
Christian Amsüss: No, if you want... if you want an extension with a single backtick because you think it's simple and straightforward, then you write a... you write a slash-equals BNF for it and it can become part of a single-pass parser.
Christian Amsüss: Ah, so the proposal is to limit what a particular extension uses in terms of ticks, but it will be up to the author of the extension whether it's single or backtick.
Christian Amsüss: Yes. And we could give some simple guidance, but yeah.
Carsten Bormann: Yeah, I would argue that it's a good idea to keep these questions orthogonal. So, you can define an app extension, but whether you use it with single quotes, with backticks, or with sequences is up to the user of the EDN and yeah, that removes a lot of complexity for a user remembering which of the variations are available for each specific application extension. So, it improves usability.
Christian Amsüss: There's also code in the... or there are parts of the document that I think would not work well... would need major changes here because right now the 999 extension describes that everything that is... the data part of an application-oriented literal is just a CBOR item because kind of when you go to the 999 form, that is what it gets turned into. This could be fixed by having differentiate between 9991 and 9992 for the different encodings. But I think it's part of the beauty of how the app extensions work is that it's not tagging a something... an EDN thing, it's just tagging a CBOR item and whatever that... however that CBOR item gets expressed in EDN, because EDN is already good at expressing like the primitive CBOR items.
Christian Amsüss: Sorry, I'm not following you. So, you're saying that if I had a triple backquoted string and I encountered a tag 999, that I wouldn't just put tag 999 comma triple backquote and whatever was inside of the triple backquotes?
Christian Amsüss: The thing about the tag 999 is that it's not for converting into another version of EDN, it's for converting into CBOR. So, in CBOR, something say hello back-back-backtick world back-back-backtick would get turned into 999 with the arguments hello and the argument second argument being a text literal world. And the information whether the whether that's from an backtick literal or from a double-quoted literal, or whether any parts that could optionally be escaped in the double-quoted literal are escaped or not, is lost because at this point this is a CBOR item and not an EDN item.
Christian Amsüss: But it's a CBOR double-quoted string, not a binary.
Christian Amsüss: It's a CBOR text string. Yeah, it's a text string. But whether it's from a triple backtick string or from a quadruple backtick string, or from a double-quoted string, gets lost because that eases the manipulation on the CBOR side.
Christian Amsüss: So, I would point out that 999 is already pretty ugly in the triple or quadruple backquoted version because you have to then all of a sudden escape all of the escapable characters...
Christian Amsüss: No, you don't. No, you don't.
Christian Amsüss: So, if I have a double-quoted string, I don't have to... I don't have to escape all of the double quotes and all of the backslashes?
Christian Amsüss: If there's a double quote... yeah, I mean, as with any other... that's my point. It's a CBOR item and there are rules for how to express a CBOR item in EDN. So, like this is already there. It's literally just you see the tag 999, you say okay the first item is a text string that has some limitations, you slap it in there, and then you have a text string item you serialize it there which is... and I think converting it into instead of a double-quoted string, if it's just a CBOR item, you could easily well just as well convert it into a single-quoted string or a three or four or 17 backtick backtick strings. Yeah, sure you can... sure I can do this. And at this point, I'm like as an implementer very close to saying as screw double-quoted strings, I'll go with backticks because like they're way less of a hassle. But we have compatibility concerns, so so there we are. But my point is more it's a CBOR item. CBOR items are something that we can work with. So, that's why I like the concept of the thing after the application literal is a CBOR item without any special rules about them. And this manifests in the string discussion but also influences the the angular brackets topic. So, it just makes it easier to handle.
Carsten Bormann: Yeah, so in summary, we have two different ways of implementing this. And we are trying to accommodate too... we have found this solution, we have tested it extensively in implementations. And now we want to unravel everything again. That's not something we usually do in the IETF. But I don't want to argue with that. I just want to point out that this is somewhat unusual behavior. I have technical reasons why I think the current solution is the right thing. I tried to explain it. Christian tried to explain it. I think there are a few other people who could explain it that are not here today.
Christian Amsüss: And I've tried to explain my point of view based on technical grounds.
Carsten Bormann: You tried. Can we use the last three minutes to look at this slide, please? So, we have had two discussions about extension points: one the application extensions and one the encoding indicators. And with the application extensions, we found that it's very clear that we want to identify a few mandatory-to-implement ones. H and B64 are kind of set because they just are inherited from 7049 from 2013. DT and IP are new, but on the other hand are so trivial to implement that most people at least on capable platforms won't have a problem to do that. So, what we said in a previous meeting, probably these are the four, and I just wanted to ask: are there any other ones that should be MTI or mandatory-to-implement? Or should we actually identify a few of these that should not be mandatory to implement? So, that's my first question. The second question is: how do we handle encoding indicators? Now, the document makes pretty clear and after some editorial fix-up it makes really clear that encoding indicators are something that is used by a diagnostic implementation. You don't have to write a diagnostic implementation. But to make sure that implementations that spit out EDN with encoding indicators are not punished for that, we declare all encoding indicators as ignorable. So, you can just read a EDN document with encoding indicators and ignore them to actually extract the CBOR data that are in there and not the ignore the additional hints about encoding variants. So, that's essentially what we came up with. So, essentially all encoding indicators are mandatory to implement in the sense you actually have to ignore them. But none of them is mandatory to implement in the sense of you have to generate them when you convert from CBOR or you actually have to create CBOR that follows the encoding indicators when there are encoding indicators present. Okay, yeah, Christian, that's exactly my problem, that I don't have a strong opinion here but these seem right. And if we want to do MTIs, we probably should just do these four. Yeah, just emphasizing briefly on on Carsten's comment here on the chat as well. Kind of I don't think that for the most recent items there has not been a strong like consensus, it's just a statement that like there was decision on. I don't know which precise point there was because you said it two or three times, but I don't know of any of those a precise working group decision. Okay, so there is a -23 out there that should help looking at these PRs. 95 happens to be merged, 97 happens to be not yet merged. And this like all previous 23 versions of this document, this is not the final document. We can still fix it. We have to fix it for PR... for issue number 103 anyway. So, let's do that and let's try to get ready for a working group last call.
Laurence Lundblade: Okay, and I will add two things, one from the chair team. One is that the the objection to "we decided" on the that's going on on the chat, and I agree with that, we need to frame this in our heads as the we had the discussion, this is where Carsten as editor thinks the consensus lay, but it's ultimately up to the chairs to make the final decision on that. And the other is that the chair team has thought that we would use the working group last call to solidify our sense of where the consensus is. So, when we do go to working group last call, it's really important that we get everybody reviewing this and commenting and saying specifically that they do or don't agree with with where things lay. Okay, and thanks Carsten for for this and we'll continue this on the list and then in two weeks. Laurence, let me give you slide control. Okay, Laurence you have slide control. Go for it. Changing deck. Okay. So, you can see the slides and hear me okay?
Carsten Bormann: Yes, we can hear you fine.
Laurence Lundblade: Okay. So, first point is that in CBOR we encourage and expect partial implementations. I mean just looking at the circumstantial evidence for that, you know, there's no explicit requirement for decoders to be full decoders in RFC 8949. We made constrained environments a target use case, I mean that's just kind of in a lot of the subjective text. And in those cases, implementations leave out... yeah, Carsten, generic decoder but I think it's used maybe twice in the whole document in 8949, maybe three times, and there's like three sentences about it. So, it's not really... and this is kind of the main point of this slide is that we have not done in RFC 8949 does not establish any kind of floor or any kind of minimum requirements or anything like that. And particularly it doesn't say that all decoders should be full decoders. We live in a world where we expect and encourage partial implementations to accommodate constrained environments. I made the slide to really underscore this point that we really live in a world where partial implementation is the rule, not the exception. And you can see this from looking at all the different... oh maybe it's full decoder that's only occurs once. Let me finish the slide and then Carsten you can comment. So, some of the and some of the features in 8949 are fairly difficult, quite difficult to implement in constrained environments, like the like the full duplicate detection, maybe it's not unimplementable but it's definitely difficult. When RFC 8949 defined preferred serialization, there's an extremely strong implication that it's okay to do a partial implementation. The fact draft-ietf-cbor-serialization exists and that we're talking about DLO, that's all license for partial implementations. Okay, so Carsten go ahead.
Carsten Bormann: Yeah, I think the important observation is that CBOR is not defined as something that you just randomly pick and choose from. But of course, partial implementations are strongly embraced, I completely agree with you on that. And that's also because we want to be able to make the life of constrained implementers for constrained environments easier, we want to make the life of people who implement CBOR in a shell script easier. So, there are lots of good reasons to have partial implementations. The point here is: who gets the onus? And saying that a partial implementation can simply constrain the sender to only use certain parts of it without that being part of the agreement, that's the part of the slide that I object to.
Laurence Lundblade: Say more about that? I want to make that's clear.
Carsten Bormann: So, I'm always thinking about interoperability. And if we embrace partial implementations, then of course we have to think about the impact on interoperability. And the point is that CBOR is defined as CBOR. And if we want to enable partial implementations, then we have to be explicit about that. Usually in the protocol definition, because the protocol definition says we don't use floating point or just does that implicitly in its data model definition. So, that suddenly enables a partial implementation that doesn't provide floating point. And that's great. But we don't suddenly make it a requirement that a receiver implementation can impose on the sender just because it is a partial implementation. It has to actually go through to the data model or other parts of the document. And it's really important to distinguish onus of the sender from onus of the receiver.
Laurence Lundblade: Okay. I mean I I think that the point of this slide is we expected, encouraged, and have embraced partial implementation big time since like day one, just because the points in the slide. So, we're there. I mean it's... okay, so what do people do partially? And just this is some taxonomy of of, you know, not the it's not exhaustive list of examples but it's a taxonomy of of what what's done partially. So, serialization is the top of the list, right? People implement don't implement indefinite lengths and sometimes they don't implement half precision and stuff like that. You might not implement major types, for example no floating point. Range, you might limit integers to 32 bits or not implement the 65-bit negative integer. What type of map keys do you implement? Like different examples so. Duplicate detection, sometimes you know the CBOR libraries don't implement duplicate detection. And then there's the big number unification. So, yeah, so I think that you know, Carsten your comment there about embrace partial implementations or consumers randomly deciding... like that's, you know, how I think that's, you know, the point. Like what are we going to do about this?
Laurence Lundblade: Okay, so and this slide kind of addresses some of this. So, protocol definitions, you know, I don't know, COSE or CWT or CRI or something, they they partially partially resolve partiality, right? You look at a protocol definition and you know which major types and tags are required, you know the range of values probably, you know about map sorting and determinization, determinism. What you often don't know and we often don't even want to resolve in a protocol definition is serialization. And that, I agree, there's an interoperability problem. So, Preferred Plus and you know and to some degree DLO resolve the main partial implementation problem. So, that's kind of the point here is that the work we're doing in the serialization draft is a lot about resolving partial implementations. It's also about other things, not just partial implementation, like Preferred Plus is a more compact representation and is also the basis for determinism. Christian?
Christian Amsüss: What I'd like to understand is... I see... when the when you say that the constrained implementation the partial implementations don't cover serialization, is is there really by the expectation by some implementations that for example an integer be encoded in the in the smallest possible way? Because my my gut feeling and from implementing is that it comes automatically that you can process if you can process 16-bit lengths at all, then it comes automatic that you can also fill in an 8-bit value from a 16-bit value that you see. So, is is this something that that does occur? That implementations reject those, or where does the implementation trouble come from there?
Laurence Lundblade: So, I think yeah, it's worth talking about this for a few minutes. I think you're basically talking about the shortest length argument, which is, you know, the arguments used for for lots of things. I I think every implementation out there can decode just about every implementation out there can decode every length of argument. In theory though, you might have an implementation in hardware that could only determine decode, you know, a 32-bit length just because it's in hardware and it's been, you know, it's it's reading and writing in and out of an integer out of a register. So, I don't I think it's very uncommon, you know, and it's a it's an extreme use case, but it's possible for an implementation to not do the shortest length argument. I don't think it's a case we have to discuss. I think it's, you know, we're trying to come up with kind of main line sort of common sort of a common thing for partial implementation with the understanding that there's always in CBOR there's always going to be some exceptional use cases that do things exceptionally, you know, for example streaming with indefinite lengths. Carsten?
Carsten Bormann: Yeah, I think the important question again is who gets the onus of doing something. We have this CBOR ecosystem that is essentially 13 years old now, where people know they have to decode things that come in, and the people also know in a pinch they can encode in a way that is convenient for them. That's essentially what 7049 is. And we clarified a lot of the details that were left out in 7049 when we did 8949. Now, what you are essentially proposing here with all these really good points you're making, but there's one thing that that doesn't make sense, which is moving the onus to the sender side. Because that means there will always be situations in which the sender doesn't get that right, and the receiver who is which is suddenly now empowered for some reason to to reject input that was valid before, creates an interoperability problem. There's just no need for this change. And I strongly oppose making such a change 13 years after we defined the protocol.
Laurence Lundblade: What change do you think is being made?
Carsten Bormann: Well, you're trying to... well, first of all, when you define preferred serialization, you don't even distinguish between the impact on the producer and the impact on the consumer. The impact on the consumer is zero. It doesn't have any benefit from that at all. So, why are we putting an onus on a producer that is not justified by by a gain on the consumer side?
Christian Amsüss: Carsten, you have made this argument repeatedly with no new information. And still, we have a large number of people who say that they want this. I think that we actually have rough consensus that we want Preferred Plus, that we want the not just the DLO part.
Carsten Bormann: What does it even mean to want Preferred Plus? What are you talking about? Which side gets which constraint? Yeah, right. You shake your head because that question doesn't have a good answer. No, that's... no, it's not a good question. The question is irrelevant. We've... there's text in the document. So, please stop being a bully. We have people who want this, like we can make some fine some fine adjustments to the text, but saying repeatedly that that nobody wants this, that nobody needs this... I mean the whole point that this document is a reaction to the fact that lot of people need this kind of guidance. Not everybody has to go and implement it has to follow this guidance, but for people who want to do a useful default thing, this is a great choice.
Christian Amsüss: Are you talking about guidance or are you talking about rules?
Christian Amsüss: I'm sorry, I didn't catch your last question, Christian.
Christian Amsüss: Is this about guidance or about rules? Because those are very two distinct things. And if you're talking about guidance that is important and Carsten objects to the rules, then we can find agreement there.
Christian Amsüss: Well, I mean, I think the guidance is: if you don't know what you want to do, or if you want to do the default thing, here are some rules about how you would go about doing that. A thing called this. Or here are a few main things that you can do. Okay, I understand. Okay. Carsten, does that change anything about your question?
Laurence Lundblade: I'm not Carsten, but I need to wrap the meeting up and I'll throw one thing out before I do that. That what we need to look at here is how we deal with sending versus receiving on partial implementations. We need to be very clear about that. So, I mean, clearly somebody who sends things that who sends a limited set of things does not have the issue. But somebody needs to be able to receive things that that are sent. And so we need that the document needs to be very clear about how that's dealt with. And with that, yeah? Go ahead.
Carsten Bormann: It is much more clear than 8949.
Laurence Lundblade: I'm I have no doubt about that, but I just want to make sure that what we get to is very clear about that so that no one can no one gets confused by the situation and you wind up implementing a receiver that can't deal with everything that comes at it. So, with that, we're out of time for the week. Thank you everybody for the discussion. Let's continue this on the list and come back in two weeks. And the goal will be to have working group last call on EDN ready by that meeting, by that interim. So, thank you again and as always thanks for the scribing help.
Christian Amsüss: Thanks, take care everybody.
Marco Tiloca: Thank you.