**Session Date/Time:** 21 Oct 2026 14:00

[00:00:14] **Marco Tiloca**: Hello, Vojtak. Can you hear me well and send audio?

[00:00:24] **Vojtěch Vilímek**: I I can hear you.

[00:00:26] **Marco Tiloca**: Hi. Great. And we are at the top of the hour now, but as usual, let's wait until four past or so before starting.

[00:01:10] **Carsten Bormann**: I just noticed that I don't have the comma revisions from thirteen to eighteen. They are not in the library that you download with an async. That's weird.

[00:01:31] **Marco Tiloca**: Alright.

[00:01:34] **Carsten Bormann**: I was trying to find the the the revision in which we removed the capability to have since as basic c four encoded numbers in your eyes, And it was still present in in 12 and isn't present in '19. So somewhere in there, we seem to have lost that text. And, of course, we want to re... Reinstitute that for the discovery things that we will talk about later.

[00:02:07] **Marco Tiloca**: And I'm I'm looking at the draft. There is no appendix with the list of changes for each version, so that doesn't help.

[00:02:16] **Carsten Bormann**: Yeah. That... That's really something that that Claude could do for us.

[00:02:21] **Marco Tiloca**: Fair enough. Hi, Dave.

[00:02:55] **Carsten Bormann**: So is everybody prepared for next week's week of confusion? I just got an invitation that that has incorrect times. So some of the times are correct, some of them are incorrect, like, what expected the read of.

[00:03:20] **Marco Tiloca**: Your public service announcement will be very much appreciated. Anyway

[00:03:24] **Carsten Bormann**: Yeah.

[00:03:25] **Marco Tiloca**: Please do.

[00:03:26] **Carsten Bormann**: Unfortunately, I really didn't have time. But, yeah, I will do this this week.

[00:04:07] **Marco Tiloca**: Okay. Now we are on top of our offset, at least. So let's get started with the people around here already. Welcome, everyone. This is Marco. This is an interim meeting of the CoRE working group. My co chairs are Carsten Bormann. And as usual, the note 12 of the IETf applies. Be familiar with that. If you're not already, it's largely about our code of conduct, so please be nice to each other and about personal knowledge of IPR. You should disclose about that if you know any or refrain from participating in the technical discussion otherwise. The agenda for today, we'll start with an item that was added only a few hours ago as a quick reaction from Carsten and Jaime together following up on the AD review of a core documents sent to the IESG a few months ago, the the pub sub architecture for co op. So there's a proposal coming up to address one of those main points, basically, that we hear about. And then the second item is collection of updates about core conf, I think, largely the the comment with most of the work done by Alexander recently, but Carsten will report, and Vojtak was also in the loop. Okay. That said, I think, Carsten, you may want to take the first item, and you have slides for that.

[00:05:46] **Carsten Bormann**: Right. Right. Vojtuk has... Vojtuk submitted slides?

[00:05:52] **Vojtěch Vilímek**: No. And I I have some slides, but there are... And they are connected only to the Yang's Seaboard Yang's Seaboard side of things. I did not prepare the slides for the.

[00:06:12] **Carsten Bormann**: Okay. Okay. So the the first item that that we do have a few slides for is what Marco just said about the the pops up discussion. So that that is... That the document... Pops up document has left the working group. And we have an AD review, and that AD review pointed out some some complexity we have been accumulating there. And I think that that's a great wake up call to to reconsider some of the choices we have made. And Jaime, with a little bit of help from me, has generated draft that will be submitted soon that defines a new success code, which in this slide said we will call two point o six. Of course, the the actual allocation of the number still has to be done. But it's easier to say two zero six than no content something this and that, and so on. So I I stick with 2206 here. And as usual, it's done the work. Has done the work. But he's in some some travel right now, so he can't present this. So I will do it. Okay. So the the... I would talk about the the pops up issue later, but what I really want to focus this on is having two zero six as a general feature that we can use in other places and other areas of application of co op as well. So it's really worthwhile for people to implement that in their co op libraries. And the reason why it may be worthwhile to do this is that there may be resources that already exist, and that for instance might be able to operate on methods like put or delete or so, but that do not have content. They don't have a representation that you would be able to get or fetch. And for a resource that never provides this capability, that's not a problem, you just don't do that. But there are resources that have periods when they have no content. But the normal mode of operation is that they do have content, that we have a representation that can be obtained with get or fetch. So pops up is a good example for that because when when topics get created, the resource that holds the current value of that topic exists, but isn't actually able to provide that resource representation because that may not have been provided to it yet. We see this... Well, generally speaking, see this during initialization, as in the PubSub example I just provided. But also in cases where content is becoming stale. So there simply is nothing useful you can say about the resource after a time... A period of of not using it. And then also, it may be a good idea to actually retract the the representation that it no longer provide. So, yeah, the answer is... The question is, why don't we use four zero four here? I have another slide providing other examples, but let's stick with the four zero four. The reason is that four zero four is is wrong. So it it tells you that resource doesn't exist, and it may may very well exist. And even if you do something... Is it a four or five? I forget the number. Method not supported, that's weird because that method will be supported, it's just not at this current point in time. And all these four dot something approaches hurt in conjunction with observe because any error response terminates observation relationships. And what you actually want to do with a resource that doesn't have a representation yet is to observe it and find out when the representation becomes available. And that's exactly what code cannot do. So, yeah, there there are general considerations, and there are considerations that are specific to to observe. And those come up in in PubSub as well, but they are more general than just PubSub. Okay, so let's try to find out what we can do with these resources. Yeah, this is a simple state diagram for what happens when you have added two zero six to something like PubSub. PubSub currently has a half created state, the name of which already tells you that that it's not exactly the best design one might be able to think of. So if you have no resource, you create it, then you have a resource, but you don't have... Don't necessarily have a representation yet. Then somebody supplies the first value. Either this is actually also done over COAP, or it's done by the back end of the COAP server that stores the resource. And then you have a resource with the presentation, and you... GET gives you a two zero five content. And then if you delete the thing, you have no resource. There is another error here error here called expire or clear. There's a little kink here that we don't have a method that would allow you to take away the representation. So we may have to think about that at at some point, but I think that that's a smaller issue in the general scheme of things. So, yeah, as I said, in PubSub, the public data resource exists before the first publication is made to that resource, and that's exactly the the no content state we are talking about, and this is emulated with a half created state. And this is really complicated, and Mike Bishop pointed this out in his AD review and and proposed doing something like no content. And and I have looked at this in a little bit more detail. So what do various implementations currently do for is one answer, as I said, that terminates observed registrations. So the client is forced to poll, that's definitely not something we want to make a feature of future protocols. One other way to do this is to provide an empty payload with a two zero five, but that can be ambiguous because the media type of this content may actually allow empty strings, zero length strings, but strings as a representation. So it would be really useful to know whether that that server does provide content or does not provide content for which we would have two zero six. And finally, we... Because we always have five zero three, but that's really something... A five zero three is something that should cause a management console to light up in red or something. And and really a server failure has not occurred just because nobody has told the server yet what the the content is supposed to be. That thing is is nice because it actually has an option by which you can say when it is worth doing the next polling. So there is some support here, but, yeah, it's wrong in in many ways. So we don't want to do that either. So one other thing that came up was that we might play with media types. So if you look at no content from a computer science point of view, essentially the number of... The set of values that the given media type can take is augmented by one additional value which says not there. And this is a lot like null and and Java or or other languages from from that era. Yeah. This is... Becomes as complicated all the the nice supporting programming languages are. And there was an idea to maybe use c eighty seven forty one application multipath core for this, but that essentially makes accept in a request nonfunctional because you only ever ask for application slash multipath core, but we don't have a version of accept that can reach in there and say, okay, the first item in the multipart call is this or is that. So, yeah, it was an interesting thought exercise, but probably not really the idea we want to follow. So let's explore this two zero six thing. And first of all, we need to agree on the specific semantics that a two zero six response code has. So it says the request succeeded, that's what the two also implies. The target resource exists, and it has no representation, no current representation that could be retrieved. So a response would not have a payload because that's not clear what that payload would stand for. It has no content format option. There is no point putting an e tag on that thing because the the e tag is a way to get a two zero three, which means the content exists, but you already have it. And so, yeah, the content does not exist, so we wouldn't use etag to do anything useful here. And this is mainly for use with get and fetch. Generally, put post patch, IPatch, delete will not use this response code, but keep the 204 and 202. 204 is changed, and 202 is deleted. Then... Laurent?

[00:18:18] **Laurent Toutain**: Yes. I I don't understand it with a post because it's... You do it with a post and you don't put content in the post and you say I'm pushing nothing, are you... It's an answer to... So I I don't see how it works with post.

[00:18:38] **Carsten Bormann**: So one way to do a patch is to to send no content back, but send a location for for retrieving that content. So... But you do

[00:18:50] **Laurent Toutain**: a post with content and you... And the the answer is no content?

[00:19:01] **Carsten Bormann**: Well, the the the patch operation or the post operation actually is free to provide any content. So that that content may not be the actual content of the resource, but it may be something else. So, yeah, maybe we should examine that in in more detail. Maybe we should come up with a couple of examples that show how post doesn't have that problem, or maybe does have that problem. I haven't thought a lot about of it because I thought that these can just keep the two two zero four and two zero two and don't really need a two zero six. Okay. A two zero six can be designated as cacheable, as you know, in CoAP. With our responses, cacheable is determined by the response code. So when we define a new response code, we have to think about cacheability really hard. We haven't quite done that. But no content with a max age, with a lifetime, actually indicates when a real representation may become available. So it's very similar to the use of max age on a five zero three, where where the seller says, I cannot do this right now, but maybe I can do that in in one minute. So we try in one minute. Of course, we want to use observe, but two zero six with max age might might be a way to provide polling as well. Yeah. And the other important aspect of two zero six is that it actually clears caches. So if you have gotten a two zero five previously, and you get a two zero six, then you know that the cache you built out of the two zero five no longer is value. No longer is valid. So this is the semantics of two zero six in short, that is suddenly not providing all the answers to questions. But I think these are the important ones. Yeah. So when you use this with observe, I apologize for my tool making the figure too small, I have no idea why it does that. When the... I actually have to zoom in on my screen to see this. When the subscriber asks for some information from a broker in core- pubsub, it gets no content as long as nobody has put a value there. And here we see a publisher that does a put on the resource. The publisher gets back back to a four because the resource now has changed. And the subscriber gets an observe notification because there was an observe option in the original get that says, oh, now it exists and you can use that value. And actually, if there is something in the broker that makes that expire that value, it might even send a notification that this is no longer true and there is no longer content there. So the observed number here, 123, of course, is the usual 24 bit serial number we use so that you you won't exactly get one, two, and three. But the example is is trying to be simple. Okay. One interesting question, of course, is what happens if the value that the publisher put into the resource actually doesn't fit an except that was on the original subscribers get. And, yeah, that... That's a weird case that we probably have to examine some more. But I think the logical thing to do would be to send a four zero six instead of the the two zero five. So resource now has content, but it doesn't actually fit the required media type, so you don't get the the media dumped at you. You just get a four or six. And that, of course, also terminates the observed because you have to think about what what to do with the except as an option at this point. Okay. So I think that that should be enough to prime your minds on how two zero six interacts with observe. Now the next question of course is what happens if we introduce this new response code thirteen years after co op was approved? And we have the usual deployment questions. So what what happens when when the various components of the system are updated and not doing things at separate points in time? RC 7,252 was pretty forward looking here. So we have much fewer problems than we could have. For instance, 7252 says response codes are forwarded by proxies even if the proxy doesn't understand the response code. So that's useful for a client getting two zero six through a proxy. And it also says you do not cache responses with unrecognized response codes, which I read as you also invalidate existing caches for this resource. But it doesn't say so explicitly, but it kind of follows from that. So I think we are in a pretty safe state. And actually, there has been a discussion recently about the support of this in loop jib coap. And after the implementers had discussed this, agreed that they want to do exactly this behavior here. So that's only one data point. We probably should look at other libraries as well. But it makes me relatively hopeful. So essentially, we have four different ways in which a client or a cache or observer could react to a two zero six. So if the client doesn't know what a two zero six is, it still knows its success. It has a two. And... But it doesn't have any more details. So section 5.2 of defines what to do here. A cache, again, that that doesn't understand two zero six is not going to stall the response, and the slide probably should say is invalidating any other caches... Cache values, cache values that it has for this resource. An observer without a two zero six simply stays registered. And finally, a client with a two zero six, yeah, can do what the the standard says. But the other three cases are important to make a transition happen. We don't want to be in a situation where sending a two zero six makes some system somewhere at the other end of the world blow up. How do proxies operate? I already said we have some pretty good proxy text in 7252 already. And the the point here is two zero six, like the other response codes, end to end. The the proxy forwards a two zero six even if it doesn't know what that is and makes sure not to cache it. An HTTP to co op cross proxy could translate to two zero six to two zero four in HTTP. I think we have to examine that a little bit more, but on the napkin it looks good. And two zero four might, on the HTTP side might... Two zero four response on the HTTP side might lead to a two zero six. Section ten one one currently yields an empty two zero five, which has the ambiguity problem I talked about. So this actually might increase the usefulness of of a core to HTTP cross proxy. So again, this looks pretty good. So essentially, we can we can state number of design decisions that will be First of all, servers always send two zero six. They they don't try to to derive from discovery information or for some negotiation information whether they can send a two zero six. The alternative here would be to have a request option that says the client understands two zero six, and the server only sends a two zero six in that case, But it seems that complexity is not required. Two zero six is is not... I don't have the content you wanted. It means I have no content at all, and I don't have the content you wanted still does a four zero six. And this is a class four response code because it means the client has to change something if it wants to make progress. So it probably has to provide a different accept option to to get another representation that the server actually has. Yeah. So so 7252 is is the the main normative reference. I think I am not quite agreeing on whether 7641 is a normative reference because this is so general, that all the examples... Many of the examples will make use of seven six four one of observe. So maybe this is a normative reference. But a lot of other information really can be informative, so we don't get a really bad strong coupling we might be getting. And we were probably going to have an appendix talking about the rejected alternatives. Or maybe we don't. That's always an interesting question. How much information do you actually move from the discussion stage to the completed RFC so we can still decide that? Yeah. So issue one I already mentioned where we don't currently agree whether seven six four one is is normative or not. That may be a matter of style to say it's normative, even if it isn't really that normative. The the e tag thing, I think... I said what I think that two zero six doesn't... Two zero six response doesn't carry an e tag. And two zero six response is very much possible to request that carries an e tag. Because it just doesn't match any of those e tags, and non existing results doesn't match any existing e tag. So to a successive to a successive valid response to that. Yeah. Number three, let's think about the interaction with accept some more, but I think we we have that nailed down as well. And then we have the the question what to do with caches that store an unrecognized two dot something. That probably requires some some research to find out do these kitchens actually exist. So this looks like a relatively straightforward program of activities we could be doing. And I think we we want to discuss those and, of course, find potential further open issues. Submit a dash zero zero to the the data tracker based on the situation we have before the draft cutoff. And then, of course, try to do another round of feedback on the core ratings. So in parallel, will make a proposal how to use two zero six in the PubSub document, which will be... Because half created has all this complexity, will be a significant change, but mostly a change that deletes stuff we no longer need. That might not be possible before the cutoff. But yeah, we probably need to do another retinoblast call on that. But I haven't really done the chair part of the thinking here Yet the first thing that we want to do is that we actually agree this is something we want to add to a co op. Questions? Marco? No, Marco.

[00:33:39] **Marco Tiloca**: Yeah. Thanks for putting this up so quickly, by the way. So it helps if you move back to page seven. I think that's the one where you have the comparison of methods. Right. So let's say that there is no resource yet. I send the put request without payload. It's successful. The result should be a resource with the content that is empty. Right?

[00:34:11] **Carsten Bormann**: Good question.

[00:34:12] **Marco Tiloca**: Well, it should be the case already today even without starting any of this work. That... That's what happens if I if I go through those steps. Right? Which is fine.

[00:34:24] **Carsten Bormann**: I actually would have to reread couple of sections to to be sure I'm giving the right answer, but it sounds right. Yes.

[00:34:33] **Marco Tiloca**: Okay. I I stressed put because I I guess if the request is post, whatever can happen, you may even have the post handler producing a resource with no content at all. Sure. So q six can follow. But if it's put, that shouldn't happen. Right?

[00:34:53] **Carsten Bormann**: Yeah. I don't even know whether a put without a payload is something you want to do or not.

[00:34:59] **Marco Tiloca**: At least you create a resource and, yeah, the content is empty. But I I don't know. It it may be a gray area that actually this response could fix this, which would be even weirder than I thought then.

[00:35:11] **Carsten Bormann**: Yeah. So I don't... Take take this as a reminder that we really have to examine those other methods instead of just going by by hunch here and try.

[00:35:23] **Marco Tiloca**: So we put to clarify and post that instead may end up with that result. I suppose that other than that, the way to create a resource with no content is just internal behavior at the server. Right? You have no other ways through a sent request.

[00:35:44] **Carsten Bormann**: Right. And and that's something that we probably should be thinking about. So that's

[00:35:53] **Marco Tiloca**: Yeah. That third case is the pub sub case, if I understand it, by the way.

[00:35:58] **Carsten Bormann**: Yeah. Does does a client have a way to generate a no content resource on a server? Or is this only four things that the server provides in its back

[00:36:12] **Vojtěch Vilímek**: end? Right.

[00:36:15] **Carsten Bormann**: So this is issue number five.

[00:36:18] **Marco Tiloca**: Right. Thanks. Taking another perspective instead, say I have a resource with no content that was created like that somehow. I send a patch or iPatch request. What's the error code I get?

[00:36:41] **Carsten Bormann**: Yep.

[00:36:43] **Marco Tiloca**: 400, probably. At least it's understood.

[00:36:49] **Carsten Bormann**: Well, the the fun thing is that the the the only thing the patch does is actually add information, in which case this could actually be a possible thing to do.

[00:37:00] **Marco Tiloca**: Doesn't this imply you you are acting on something that is there to massage?

[00:37:08] **Carsten Bormann**: It it actually does. So I agree. This is not a clear cut thing right now. So probably we should think about the error code for that.

[00:37:18] **Marco Tiloca**: Okay. And, yeah, a a last comment, is related to one of the later issues. Number one, I think, on updating 7641. Yeah. I I think so because that mentions that in reply to a successful get or fetch with Observe, you get 205 or 203. So if you introduce an alternative more that deserves an update and if I got it right with the previous comment, the same would be for updating 8132 for introducing or defining clearly a behavior when you send the patch or iPatch request to something existing but without content.

[00:37:59] **Carsten Bormann**: Okay.

[00:38:02] **Marco Tiloca**: Yep. That's all I have for now. Thank you so much.

[00:38:04] **Carsten Bormann**: Yeah. Thank you. Dave?

[00:38:10] **Dave Robin**: Yep. Hi. I'm I'm not an expert on co op, so I I don't wanna comment on that part. But when you mentioned mapping to HTTP is when I perk up. And, specifically, if you said, this... I'm glad you have this slide right here because you say used with get and fetch and then implying that you... It is not used with put, post, patch, etcetera. And that might be fine in the co op world. You can say, don't use this with put. But when you're mapping from two zero four, HTTP two zero four, which is, you know, well defined semantics in my world of HTTP, then an etag is possible on a response to put. It represents the the entity tag for the new the new resource, which is none. It has no content. So it's just one more thing to throw in as you're as you're thinking about all the consequences of this fan out. If you're... And if four zero four... I mean, I'm sorry. A two zero four from the HTTP side comes in as a response to a put, it might have an e tag in it, and you have to decide what what you wanna do with that down at your world if you're not going to map that blindly to a two point o six and then say that two point o six never has an e tag. So just something to look into, I'm afraid.

[00:39:35] **Carsten Bormann**: Yeah. On two portals

[00:39:36] **Dave Robin**: Is it related to the... You're right. That this this seems really clear cut on... And I I can't believe it's not already there because, you know, the the two zero four... 204 on the HDB side is very useful. And, not having a no content in CoAP seems, like, it's amazing that we got along with that for so long. But when you're trying to map it to an HTTP two zero four, it it might get tricky, through proxies and stuff. As you've identified, I'm just throwing out one more thing, with... As it relates to the etags. Does... It it... See, you might think an etag doesn't make sense, but in HTTP two zero four, it does for a put. So

[00:40:19] **Carsten Bormann**: k. Thank you.

[00:40:21] **Dave Robin**: Yep. That's all.

[00:40:29] **Marco Tiloca**: Any more comments, questions? I guess you got quite some content to digest, Carsten.

[00:40:38] **Carsten Bormann**: Yes. Thank you. Yeah. Yeah. I apologize again that that will... Wasn't able to to come here, but he had some traveling with kids and and family and so on. So he really couldn't make it. Okay. I hope I have done his input justice here in my presentation. So I think I'm up with the next item on the agenda as well.

[00:41:08] **Marco Tiloca**: Yes. Go ahead with swapping slides if you can.

[00:41:12] **Vojtěch Vilímek**: Yeah.

[00:41:13] **Carsten Bormann**: So I didn't really create a lot of slide work here because these are usually pretty complicated issues. And it's hard to describe that in exhausting detail in a meeting, but I would like to alert you that certain things are happening. And based on implementation experience to a large part. And I think it's very good that they are happening. So most of the work is done by Alexander Pillov and his team. And again, I'm I'm just reporting this here. So what does is it tells you how to operate on a Yang server using CoAP. So it... It's kind of a to the question, how do you represent Yang and Cboe? But, of course, it makes use of of Yang and Cboe. So the the two documents are somehow related. But I think we have very few problems between this document and ninety five fifty four at this moment. So let's focus on what what we have to do. There are currently eight issues open on GitHub. I think we need to get a little bit better actual recording issues. I think the the more interesting list is the pull requests that have been created from these issues, but it's still useful to read the issues. For one, because we are not sure that we have covered all them with pull requests yet. And also because some of the discussion that led to the pull request actually happened in the issue. That's a problem with apparent seeming independence between issues and and pull requests, which are hard to get right in in a user interface like GitHub. So instead of going through the issues, let me just go through the PRs. There are 11 PRs out there in different states of completeness, and I'm sure that that Vojtig will say more about that. So Vojtig just jump in whenever I'm I'm saying something that is not giving the whole thing enough justice. So some of the pull requests actually mention in the title, which issue they are supposed they are supposed to address, But we haven't done this consistently. So maybe we want to do this at some point. So let's again not look at these 11 PRs, but try to sort them a little bit. And there are some seven PRs that are editorial and or small fry. Editorial PRs are not necessarily trivial, and they may need a lot of attention to make sure that we don't break things while doing the editorial cleanup. So there is one catch all, number 36, that provides answers to a few things that came up. Number 35 is true editorial work, creating an annex that lists the SIDs used in the examples. So it's easier to use the document without necessarily having 10 AYANA web pages open to find those SIDs. Number 34, adds examples of RPCs and actions without input. That's the typical mistake that one makes. You always want to write examples to completely cover a topic, and then you are not considering subsets of that topic. So that's 34, adding examples. 33 is another example thing where we want to have example payloads for each media type. 32 is is the previous version of 36, so that there... This again a few corrections that should be noncontroversial. I don't remember what 28 is, but I think it's also again something that needs to be... Just needs to be added on an editorial level. And then we have this wonderful new document from on quite diagnostic notation, which I think we want to properly use and want to get some comments on that. So this is editorial work, but it does... That doesn't mean it's not technically relevant. And it does take a little bit of concentration to get this right. Okay. So these are seven of 11, and now I have slides for the not so trivial points. And one observation that Andy made was that we have been not quite using IPatch right because per RC eighty one thirty two, IPatch is atomic. So if you do a patch, you are supposed to do all of it or error out and do nothing of it. And we we were trying to make the the life of a very constrained implementation easier by having the implementation operate on the components of an iPad sequentially and abort when one of the actions doesn't work. We may want to look at this some more to ensure that we we actually have a decision here that does not cause a lot of complexity in implementation that we really cannot cannot afford. So, yeah, we we have a pull request, but I think we are still missing out on discussion what that means for an individual implementation. And I think it would be important for implementers to actually look at this. So this is the pre request number one I want to point you all to. The second one is at some point we believed we had had gotten rid for COMI of the need to have SIDS in URIs. Because we usually put SIDS in in the fetch payloads, and they are nice and and short there. In URIs, they need to be expanded as base 64, which is both using mobiles and also using more code. Now this this was kind of... We had our blinders on when we did this. Discovery may actually do deep linking, in which case you actually need SITs. So discovery may give you a URI pointing to some specific place in the data tree. And the result of that discovery is expressed in a single UI. So you don't get fetch input that you would use with data store UI or something. You really get a single UI that needs to be able to to go deep into a data store. So we had a definition before we started. I noticed that for some reason, the the archive of Internet drafts here is broken somewhere between revision 12 and revision 19. We removed the text, so we have to reinstate that, and then we should be happy again. But we probably need a few examples why we think this is still needed.

[00:50:17] **Vojtěch Vilímek**: I maybe jump in for a second.

[00:50:21] **Carsten Bormann**: Yes, please.

[00:50:23] **Vojtěch Vilímek**: The thing is that the u... URIs, I... Are used when you want to discover the young data nodes that are available on the server, and the URI format is used because it is required to be used by the format for the discovery. The the the link constraint, like, web linking format from the RFC, like, sixty six ninety or something like that. And it is never used anywhere else because when you want to fetch some data, you use the SIDs or the identifiers based scripts from the SIDs. And this is also not the only option for querying. There is also option that is Yank library together with SID files, which contains the mapping from the young tree names, string names to the SID integer and identifiers.

[00:51:44] **Carsten Bormann**: Yeah. I think that that... That's an important observation. Where would that actually be used? The... One of the the features of YANG is that the way things are addressed in YANG is is deeply entangled with the way XPath works, which was great when YANG originally only was XML because at least capable implementations of XML usually includes some XML processing. But of course, with RESTCONF, which is JSON based, and CORECONF, which is CBOR based, that no longer is a good fit. And we have been dancing around problems here, for instance, by restricting the query parameters that we actually support to keep constrained implementations of core con servers, of command servers, from having to implement all of x path. X path is a Turing equivalent notation, and that's not something you you want to have on a class one or class two system, and probably not even a class three system. So, yeah, we we we have to look at places where the Yang documentation tacitly assumes that we have all the power of XPaths available to us, and therefore doesn't provide a feature that could be implemented with less effort than XPath path. So the RFC you just mentioned was sixty six ninety?

[00:53:42] **Vojtěch Vilímek**: Yes. I believe so. I will check that. Okay.

[00:53:54] **Carsten Bormann**: So this is just the definition of link format. Yeah. I I seem to remember what the UI was. Exactly. So link format also is one of those things that are text based. And we have learned that we we usually like to have ways to not pass text. That's why we have been going away from that. But unfortunately, the replacement for link format that we have been working on hasn't materialized. So link format is still out there and very important. So... Yeah. Laurent?

[00:54:35] **Laurent Toutain**: Yeah. I'm not sure to understand all the the prime, but I I made an implementation of of this. And when I want to discover resources... So I did it, but I removed it because it was no more in the draft. But you you have the depth parameter, and you can say, let me see this at this seed and go depth of one. So this way, you can discover what you you have under. And I don't see why we need to to put your eyes in in this.

[00:55:13] **Vojtěch Vilímek**: The URIs are basically a hack to put the SIP number into the because the constraint link format uses as the primary identifier, the URI.

[00:55:31] **Laurent Toutain**: The constraint link format. Because it was before you put the base 64 adapted version of your URI... Of your SID in in the URI, but it's it's quite ugly and...

[00:55:49] **Vojtěch Vilímek**: Yes. As I as I as I said, I think it is mostly a hack to encode the seat number into the u r I... URI string.

[00:56:00] **Laurent Toutain**: Yeah. But what I... Because I don't understand is that when I'm doing core conf, I may use a core con... Kind of core conf discovery more than something that is really a rest discovery. And the depth, for me, it's a good way to to discover things, exploring the model without going too far.

[00:56:32] **Carsten Bormann**: Yeah. So what what you're trying to say is that we don't have to use link format sixty six ninety discovery on its own. We can combine this with other kinds of discovery, and that's certainly true. I think the question would be whether we want to force people to do that or whether we want to provide a way to come from a UI into somewhere slightly deeper in the service data structure than than we could. Yeah.

[00:57:07] **Laurent Toutain**: For me, a link format will suggest slash c and you have a call after that.

[00:57:13] **Carsten Bormann**: And Yep. So essentially, let me phrase this as do we want to support deep linking or not? And so the assumption has been that we don't have to do that. And we have fetch for the actual interaction, but we don't have the deep linking support Yeah. On the discovery side.

[00:57:35] **Laurent Toutain**: And I don't want to delay too much, but the use of depth was could be something very valuable, but maybe in the next version.

[00:57:49] **Carsten Bormann**: Yeah. The the problem with depth is that it still takes in any breath. And I think Andy's comment that we really need some form of pagination at some point is correct, but I think we have to talk to to constraint node implementers to find out what what is a good way to do pagination through the data source of those constraint nodes. So I think that's indeed something we want... Maybe want to do in the next round.

[00:58:29] **Laurent Toutain**: Yeah. I'm not a embedded developer, but we we made a... We've managed and Javier a c version of of core conf. And in fact, it's only static memory with integer and all that stuff, and we just go to CBR at the end when we ask for something. But we want static storage, not dynamic memory in... Inside the embedded system.

[00:58:59] **Carsten Bormann**: Yeah. So I I register that there is some resistance against adding this stuff back. And I think we need to continue this on the mailing list. We can do this in a separate document. So it doesn't have to be part of base comma, it can be an extension. And it would be about links provided by the server and and its discovery information. So the server would be able to choose whether it wants to use this functionality or not. And very constrained server simply would not provide it. I think that that's a way to handle this situation. Okay. Next item. We thought that that merge patch, JSON merge patch, is an easy way to to do a basic iPatch application. MuchPatch operates by giving null, adjacent value null, a special meaning if you put it into specific places, the whole construct you you put it into vanishes. So it's not just setting something to null, but the whole thing goes away. And it turns out that null is already used in Yangtzebo for a few things. So when you want to update something that is expressed using a z1 null and Yang SIBO, you might inadvertently trigger this mechanism that removes the whole thing. And that's ugly, that it's probably really hard to fix all the special cases in which that happens. So at some point we said, well, Cboe has undefined. Why don't we use undefined for the... This is supposed to vanish situation and keep null with the meaning that it already has in Yang's heap. So at least I perceive this as a relatively noncontroversial change, but it's a non trivial change that actually changes interoperability of IPatch. Patch and IPatch situation, so we should do this very consciously. But I hope that the consciousness will come up with supporting this change. So that's number 25. And then we have the question about handling event streams with empty messages. And I must tell you, I don't fully understand the discussion yet, so I need some more time to fully wrap my head around that. But I think the important observation is that when you want to send a notification, there may be a good reason to send a notification that essentially is empty because nothing interesting has happened. And therefore, we want to allow some form of empty message. And the question here is essentially what was the best way of doing that. And some of the discussion sounds a bit like the confusion we sometimes have between empty arrays and empty encodings. An empty array still needs a byte that says, hello, I'm an array and I'm empty. This is hexadecimal 80. And then empty encoding means you don't have any byte at all. And now this is further confused by the fact that these things are often wrapped in Cboe byte strings. So you have to talk about either the unwrapped thing, which may be an empty array or completely empty, and the wrapped thing, which of course has a Cboe header for a byte string in it. So there are about four ways of doing things, and it's relatively easy to get confused if you only think about this in terms of of the encoding. If you think in terms of this... About this in terms of data types, it's pretty obvious what needs to be done. So, Vojtig, you probably have some more detail you can supply for that.

[01:03:49] **Vojtěch Vilímek**: Sure. The the the basic motivation is that the text as is in the version version 21 is that when you subscribe to a notification stream, event stream that that sends out the notifications, the server must return at least one message... At least one notification. But what if the server has not created any notification yet? What it should return? So the the proposition was to allow empty notifications or empty messages for event streams that has no notifications. So when an observation is created, it... Nothing can be returned, but the answer will be basically empty list as... Oh, I think it is CBER sequence. So it might be entirely empty. Like, no no bytes at all. But you get get the message that the subscription was successful and the server counts... Consumed among the subscribers.

[01:05:10] **Carsten Bormann**: So, of course, this could also be done with the two zero six? Yes.

[01:05:16] **Vojtěch Vilímek**: With 206 code.

[01:05:20] **Carsten Bormann**: But maybe it's not necessary to create this level of coupling here. So an empty sequence, which is again something different, might be a good way to actually get this done. Okay. So we can let Because...

[01:05:45] **Vojtěch Vilímek**: Sorry. Be... For interrupting you. Because the base content format for the event streams are sequence of the notifications. So Right. The sequences propose the pattern.

[01:06:05] **Carsten Bormann**: Makes sense to me. Okay. So it's ten days before the internal draft deadline. So I think we have to be a little bit modest with our expectations what we can do here. But to me it seems if a couple more eyeballs look at the PRs, There should be at least half of the PRs that we actually can match because there there is no confusion about them anymore and that everybody agrees that they should be done. And the plan should be to submit a dash 22 with those agreed PRs applied, and then we can take the slightly more difficult PRs that we don't have agreed on to San Francisco. And well, I won't be there unfortunately, but we might still have some some partial hallway conferences and try to fix things. So who in this interim is going to San Francisco?

[01:07:29] **Dave Robin**: I am. I assume more are.

[01:07:34] **Carsten Bormann**: You are and?

[01:07:38] **Dave Robin**: Oh, Dave. Sorry. I mean, I'm

[01:07:40] **Carsten Bormann**: Yeah. No. You you said something. You are going to San Francisco, and then you then you said something to San Francisco.

[01:07:46] **Dave Robin**: Yes. I I assumed that most of us would be there, but maybe I'll be lonely. Well,

[01:07:54] **Carsten Bormann**: for some of us this is equivalent to having a meeting in Somalia. So... Agreed. Agreed. Not necessarily. I have heard heard from a lot of people that they don't want to come.

[01:08:06] **Dave Robin**: I I I under... Fully understand.

[01:08:12] **Laurent Toutain**: I take the risk.

[01:08:15] **Carsten Bormann**: Thank you, Laurent. Okay. So maybe we can... Vojtak cannot be present. I think we should try to to run... Maybe run something like a site meeting, but not an official site meeting. Site meetings are never official, so this is an accelerant. But just sit down in some corner with with a laptop that is in a conference and get some discussion going with present people and people that cannot be present. And then, of course, we still have the call working group meeting where we can do some official progress on these issues. So who will be at the hackathon?

[01:09:15] **Marco Tiloca**: I plan to be around there and not exactly working on, I should be around.

[01:09:21] **Carsten Bormann**: But but virtually Remotely.

[01:09:24] **Vojtěch Vilímek**: Yeah. Sorry.

[01:09:25] **Carsten Bormann**: I definitely will be around at least in in the morning and the afternoon, probably not at the evening because I do like to have some sleep occasionally. So, Laurent, I think you are coming physically to the.

[01:09:42] **Laurent Toutain**: Yes. I I will be there. Normally, I pass to to work on call confirm to him.

[01:09:50] **Carsten Bormann**: Yeah. So this is... We've got... So this is just a reminder. It may be worth finding slots at the hackathon weekend where we communicate between people that are present in the room and and people in other places of the world. Good. Any more comments on this set of slides?

[01:10:23] **Marco Tiloca**: Not on this exact slide. As a side thing, I noticed a resubmission of young metadata. Just wondering if it was only a revamp or or there's any news you wanted to share.

[01:10:36] **Carsten Bormann**: Yes. I resubmitted this because Laurent allotted me to the fact that people may be misunderstanding what it means that this draft has expired. The problem with this draft is that it appears to be a no brainer. So nobody comments on it, and it appears as if the thing doesn't make progress. So if you have any comment on on the way to do metadata in Yangtzebo, it would be useful to to make this comment. Now we probably do need a couple of reviews of this document also from people who are more active in the YANG community. Because if we have a regular bus call of this thing here, of course, a lot more YANG people will look at this and will tell us that something we did maybe wasn't so bright. So, yeah, thank you for the pointer to the young metadata document.

[01:11:49] **Laurent Toutain**: Yes. There is people from the draft that are using it. So I will push you to take contacts with the group because they asked me some. Am a seed expert for the allocation of seeds, and so they asked me some technical question on metadata metadata, and so I will Yep. Ask them to go to the group and discuss with you.

[01:12:18] **Carsten Bormann**: Great.

[01:12:23] **Marco Tiloca**: Thank you, Laurent. And thank you, Vojtak. Laurent, check the chat, and be sure to forward anything to Vojtak too. Okay. We are at the end of the agenda as mentioned when the meeting started. Do you have any other points to discuss today? Hello, right now. Thanks a lot for your work and for today. Talk to you in two weeks.

[01:13:03] **Carsten Bormann**: Yeah. So maybe just looking at the timing, the next meeting is in two weeks, which is two days after the internal draft cutoff. So all communication that we want to have on on drafts that go into the San Francisco meeting has to happen before the next interim. But then we will have a really relaxed interim where all our drafts are submitted, so we will have time to actually get a few more things done. I see

[01:13:34] **Vojtěch Vilímek**: I may want to note only that I finally managed to create the PRs to the pyang... The core core working group fork of pyang. So they are pending there. So review is needed, but I think they are ready, basically. But I will I will send an email to the working group and also to the Yank two link mailing list to have people not... Notified.

[01:14:21] **Marco Tiloca**: Thank you. Anything more? It really seems not now. Okay. Thank you again. Talk to you in two weeks.

[01:14:36] **Carsten Bormann**: Talk to you in two weeks. Right.

[01:14:37] **Dave Robin**: Thanks,. Bye bye. Bye bye.

[01:14:40] **Vojtěch Vilímek**: Here you are.