Session Date/Time: 22 Apr 2026 06:00
Lorenzo Corneo: It’s 8 o’clock here, Central Europe time. Let's wait a couple of more minutes to get more audience joining. Good morning, Bart.
Lorenzo Corneo: Okay, it's two minutes past. Welcome everybody to this ASDF interim number five. Let's go quickly through the chair slides. Anyone taking notes?
Ari Keränen: I can help here.
Lorenzo Corneo: Thank you. And then this is the agenda for today. So, I'm going to do some administrative and present the Note Well as usual. And then we have quick update on the digital twin draft. And then we will discuss the documents currently in working group last call, which are the nipsey draft and the SDF protocol mapping. And then we can discuss if there is any other business, like for example, should we meet in Vienna, etc. Or also when we schedule the next interim. This is the Note Well, the reminder of the IETF policies which you have already agreed by joining this this meeting, and in case you you want to know more, there is the QR code and you are invited to go there to get more information about that. And this is the code of conduct guidelines. I leave it there for five seconds. Okay, said so, we can get start with the topics. I'm going to load the digital twin slides and I guess Jungha will present. I’ll give you the control for the slides. Yes, Jungha, please go ahead.
Jungha Hong: Okay, thank you. Can you hear me?
Lorenzo Corneo: Yes, loud and clear.
Jungha Hong: Hello everyone. I'm Jungha Hong from ETRI. Today I will present our work on digital twin. This version includes how digital twins can be modeled using SDF and how they can be made operational through protocol considerations. Let me briefly explain the updates since the previous version. We added a new section on protocol consideration in section 5. We also included supported protocol types such as MQTT, CoAP, and NIPC. In addition, we refined the document and corrected editorial issues. This slide shows the structure of the document. In this version, we mainly focus on protocol considerations and how they enable digital twin realization based on SDF modeling. Digital twins require continuous communication with physical objects and reliable synchronization. To support these requirements, protocol binding is necessary. In other words, SDF provides the semantic model and protocol enable actual communication and operation. So, we can say that SDF plus protocol equals an operational digital twin. This slide shows the supported protocol types. Different protocols can be used depending on system requirements. For example, MQTT can be used for sensor data and status reporting. CoAP can be used for constrained device interaction. BLE is suitable for local communication with embedded devices. And NIPC can be used for non-IP based systems. Each protocol plays a different role in digital twin systems. To connect the digital twin with the physical devices, we introduce protocol binding using SDF protocol map. This allows each element in the SDF model to be mapped to the protocol specific parameters. For example, BLE can be used for data exchange and device control and MQTT can be used for status reporting. This approach enables a protocol neutral model while supporting multiple protocols in real deployments. This slide explains QoS and synchronization. QoS defines how reliably and frequently data is transferred. For example, update intervals determine how often data is updated. This is especially important for telemetry data such as SDF property updates and for command response interactions such as SDF actions. Proper QoS and timing control ensure consistency between the digital twin and the physical object. When binding protocols, security must be considered. This includes authentication, authorization, secure communication, and metadata protection. In terms of implementation, it is important to choose appropriate protocols based on device and network characteristics. Also, both push-based and pull-based communication should be supported and standardized identifiers should be reused. Finally, conflicting protocol bindings should be avoided. Next step. As the next step, we plan to extend this work to AI agent-based digital twins. By combining digital twins with AI agents, we can move from passive systems to active systems. This includes capabilities such as inference, decision making, and autonomous control. In other words, digital twin plus AI agent enables intelligent and autonomous operation. Thank you for your attention. Have you any questions?
Lorenzo Corneo: Thank you, Jungha. Great presentation and good updates. I have a question actually. I think in slide 5, you list a bunch of protocols. We currently do not have protocol mappings for all of those. And I was wondering, I think you're a bit ahead of what we have currently. So, I was wondering if you're also considering standardizing some of the missing protocol bindings.
Jungha Hong: No, this is some examples of the protocols. This is the protocols list to be considered.
Lorenzo Corneo: Okay. So but I guess if there is something that we should add to to the SDF ecosystem that should happen through the SDF protocol mapping registry, is is that the case?
Jungha Hong: Yes, if possible, the some the protocols can be added in the SDF protocol mapping, but this is just list of protocols to be considered or supported. That's all.
Lorenzo Corneo: Okay. Yeah, no but that's fine. I was just wondering about how how to ensure that that these are compliant with the rest of the ecosystem, of the SDF ecosystem. But but this looks good to me, so no issues. I was just wondering.
Jungha Hong: Thank you for your comment.
Lorenzo Corneo: Thanks to you.
Ari Keränen: Yeah, I think you made a good point. Maybe it's worth putting a note in this draft that not all of these are supported by the current spec yet and could be for future consideration, that someone doesn't get the impression that you can already do this, because of course this draft is informational, it's about how you use digital twin, sorry, how do you use the SDF technologies to build digital twins, that someone doesn't go: "Oh, you can actually do already MQTT before it's standardized". Just putting a note there that it's for future consideration and then we definitely should take a look at the protocol map future versions or the registry extensions, how and if we should do that.
Jungha Hong: Thank you, Ari.
Lorenzo Corneo: Yeah, I think that's a good point. Thanks thanks, Ari. Do we have any more questions? Okay, I guess we are up with the time. I want to thank you again Jungha. Great presentation and great work. Glad to see the update. I guess we can move on now to NIPC or SDF protocol mappings. Who's gonna take the first tab? Rohit or Bart?
Bart Brinckman: Thank you. Hello, can you hear me now?
Lorenzo Corneo: Yes, absolutely.
Bart Brinckman: Okay. Hey, good morning everyone and good evening to the folks on the other side of the respective ponds. We did have a new NIPC release kind of addressing all Ari's comments and Carsten's comments. We didn't really create any slides around that. So I'm I think most of Carsten's comments were I would say editorial, right? So I don't I don't think it makes a lot of sense for us to kind of go through them and and thanks for the help Carsten with all the kind of with folding and so forth. Ari produced a report by our good friend Claude, right? Who took a look over the the spec and we did kind of address all those issues or, you know, provided a reason why, you know, we didn't agree with Claude. So what we and we included that kind of feedback in the the document that was generated. I'm happy to walk through though I think they are eighty eighty odd issues if I'm sorry, thirty, thirty issues. Yeah, so we can I'm happy to walk through them if the the group thinks this is useful and there's time. But but yeah, but we did you know address all of them.
Lorenzo Corneo: I mean, we have time. So it's the rest of the meeting except maybe five minutes to discuss any other business, mainly thinking on next meetings, then you have full control of the meeting. But I see also there's some people in the queue and I would start with Ari.
Bart Brinckman: Okay.
Ari Keränen: Okay. Thanks, Bart. I was wondering where should I look at the changes? I was looking at the diff or the latest draft and I didn't see that many changes. Ah, sorry. There's a lot in the end. Maybe, yeah, if you can somehow help map like where should I look for each issue? And now now I realize there's a bunch of things in the open API specification in the end. If you can go through the substantial issues one by one, that would be maybe helpful. Like how did you address them?
Bart Brinckman: Yeah, we'll do that. Yeah.
Lorenzo Corneo: Yeah, that's exactly what I wanted to say. It would be nice to have a little roadmap or tour through the changes at this point because it's lots of details that are changed in the document, but there are probably some interesting structures to that.
Bart Brinckman: Yeah, so let me go, so I should be able to, I'm requesting a screen share here, Lorenzo. It didn't work. Can you try again? Okay. There you go. Spec issues, just a second. I need to find the, yeah, there we go. I'm hoping you could see this and it's legible.
Lorenzo Corneo: We can see, but probably you can zoom in a little bit.
Bart Brinckman: Okay.
Ari Keränen: Yeah, and and apologies, I now realize I missed this email. Now I found it. But thanks, let's do the run through here.
Bart Brinckman: Okay. Is this better?
Lorenzo Corneo: Yes, yes, I would say so. At least I'm happy with that.
Bart Brinckman: Okay. Make it a little wider. All right. So number one, delete put registration models. So the section, the text says a list and the model shows an array. So we this is basically a fix in the text. So Ari, so the we fixed the text on this one. So it's not a list, it is an array. So that was an easy fix. Data app registration events field array versus string. This is kind of the same thing. So this is an error in the text.
Rohit Mohan: Yeah, there was a section 8.2 which had a couple of examples and all the examples weren't updated.
Bart Brinckman: Yeah. So the the first yeah, there's a lot kind of a few of these that are similar. Status field 200 section 8, where the examples weren't updated. Yeah, this is examples that were not updated based on kind of latest changes. Section 8 also examples that wasn't updated on so the example was updated. Query parameters where path segments, yeah, so this is like our long-lasting discussion around path and query parameters. So the model Claude also flagged this one, so we decided that we're going to use query parameters for you know all the reasons we discussed. So we did not update, obviously update this one.
Ari Keränen: Maybe quick pause here. I mean, I I agree that consistency makes sense. I was wondering if it would make sense to note something on the draft like a implementer's note or something if someone else is wondering the same thing.
Bart Brinckman: But we did actually dedicate a section to that.
Ari Keränen: But this but I guess the fact that this one of them is in a different place, was that mentioned in that section? Now I don't remember. That for consistency also this one, the data app ID and the instance ID also go.
Bart Brinckman: So we mentioned about the fact that we have to put them in query parameters, but now I don't remember, do we mention that for consistency we also put data app and instance ID same way.
Bart Brinckman: Yeah, um yeah we can I can take another look at that section, but I think we we kind of just kind of mentioned that kind of all the you know all the identifiers are in yeah are in query parameters. So
Ari Keränen: Okay, then maybe it's then good already.
Bart Brinckman: But we can I can take another look at the section to see if yeah if we need to explicitly mention this.
Ari Keränen: Thanks.
Bart Brinckman: Yeah. Registration models returns 200 not 201. So we updated that. Action status enum. So this is yeah this is again a text issue, so the text was updated. So in progress completed will be upper case per the CDDL. Yeah, so this is intentional because the trigger response the response for device triggers and group triggers should be different because we know we in the in the first case we kind of know the device ID and we don't know the instance ID. In the second case we know the...
Ari Keränen: Bart, sorry to interrupt. Can you give a bit of context here for everyone? Because now this might be a first issue where you're not, you say it's intentional that it's this way. Give a bit of more context, what is actually the issue before telling how you address it.
Bart Brinckman: Yeah, so if you so when you install a trigger on a device, right, so a trigger includes basically the action that you or you actually this is a get. So when you install a trigger on a device, the trigger includes the action, but it also returns kind of an instance ID. Now the instance ID refers to either a trigger on a device or a trigger on a group, right? So if you do a get of of a of a trigger of a device, you pretty much already know both the instance ID and the device ID. But if you do a trigger on a group, we need to return all the devices that are in that group and the instance ID doesn't have the instance ID because the instance ID is linked to the group not the device. So we have to return all the devices where it doesn't make sense to return a device ID in when you query a single device. It makes a lot of sense to return the device ID in the array of devices that are, you know, have triggers installed in the group. So so that's why they're different.
Ari Keränen: Okay, thanks. I guess I'll have to take a closer look here. But thanks for the explanation.
Bart Brinckman: Delete registrations data app returns the deleted body. So we discussed this, I mean, it it is I think it's not a a bad thing, but it's probably not really useful information, so we we fixed that, we're not doing that anymore. So we followed the recommendations here to 204 no content. Post registration model no idem-potency. Spec does not return. Yeah, so we did update that, so we we added a an error type which is the SDF model which with SDF model already registered. So we added that.
Rohit Mohan: Yeah, we actually already had the error type, we just added a line saying that we will return this particular error.
Bart Brinckman: Ah, yeah, yeah, we already had it but it wasn't in the text. Yeah. Paginations. Yeah we there is a point like you know if there's a long list of models or data apps we could support pagination, but we haven't really foreseen this at this point. I mean, it I think it would require substantial changes. So I don't know Ari what you think about this, but...
Ari Keränen: I wonder why why do you think it would be substantial? It would typically just be a query parameter saying like how many would you return and another query parameter for pointer.
Rohit Mohan: But I guess the response would also have to change, right? Because I believe the response today is just a list.
Ari Keränen: sorry, can you say again Rohit?
Rohit Mohan: the response would also have to change, right? when you're doing like a pagination, like you'll have to say what's like the count or you'll need to know like if there is another page to fetch or not. Like today the response is just a list.
Ari Keränen: You don't necessarily have to. I mean, of course now it's a bit of a design decision and how much hypermedia would you would you use here. But in a simplest form you could basically return a cut of the list, you know, and say like just like you do, now you return the full list, but now in the paginated version you would return a subset of the list basically saying like, I mean there's a few different ways to do it. Um, some one way that is typically the you know page style, page one, two, three, four, and each page has, you know, N elements, or it could be, you know, some some range defined. Um, and like I don't have a strong opinion here. I guess the key question here is like do you envision there will be lots of massive responses in some cases. Um, like if it's only ever let's say 50, yeah, no bother. But if there could be 50,000 or let's say a thousand, it might be useful for some applications to be able to do a pagination there.
Bart Brinckman: Well, we kind of like typically the number of I mean typically the number of data apps we see you can count on one hand, and also how many different I mean at least in the scenarios that, you know, we are deploying, the number of models are also relatively, you know, sub, you know, in the in the teens or or less. So yeah, I mean, obviously Ari I kind of agree we have to, you know, we don't this spec could be used in different scenarios as well, right? Um, but I mean it's not I don't feel like like in current implementations we would need it.
Ari Keränen: Yeah, I mean I'm not feeling strongly about it, but I think it's a good thing to consider and I think the implementation can be quite easy. So maybe what I would recommend is take take a look at some of the existing pagination ways and see if it's a reasonable, if it's a lot of implementation work, yeah, I wouldn't bother. If it's trivial thing to do, maybe it's worth considering. Like the ones that I have at least implemented pagination have been quite easy. The tricky thing there is of course if the list changes while you iterate through it through pages. So that's kind of the thing, whether it's a relevant consideration or not is another thing, um but that's kind of where it gets tricky. Otherwise you can use a simple one query parameter that you say like one by one. One alternative is to have in the payload a pointer, here's the next set of the list, the hypermedia style. The other one is just having a query parameter on on the spec. So there's different just different ways ways of doing it. Um, but yeah, maybe it's worth a bit quick consideration but it might be easier than maybe you think to implement.
Bart Brinckman: Okay. Well we can we can take another look at this.
Ari Keränen: Thanks. And of course can be a future extension to when we see need for it.
Bart Brinckman: Okay. Disconnect response body. Okay, so I think this one was fixed, we changed this to 204. Did we change this to 204 Rohit?
Rohit Mohan: Yeah, we just don't return a body now. Previously we returned a body with just the ID which was kind of useless.
Bart Brinckman: Yeah. I think this was something that was addressed before, I think we just forgot to remove it I guess. Yeah. Mixed use of SDF name. sorry, Ari.
Ari Keränen: Yeah, actually Lorenzo, can you take over taking notes? I realize I have hard time taking notes while talking.
Lorenzo Corneo: Of course.
Ari Keränen: Thanks. sorry go ahead Bart.
Bart Brinckman: So mixed use of SDF name. so yeah, I think this was an artifact of a trigger being both an action or an event, so we used the SDF name keyword then later on we moved it to just being events, so we changed this to event name. So I think this is more clear as well. So the the SDF name that identifies the affordance that fires the trigger is now is always an event, so we changed it to event name.
Ari Keränen: sorry let's pause here for a moment. Because I think it was not about... Okay, maybe I'll need to take a look offline, because I think the event name for SDF name sounds semantically slightly off.
Bart Brinckman: No, but it's always an event. So
Ari Keränen: Event afforded? sorry I have I have to spend a bit time to try to return to the context of this issue. Um, okay maybe I'll take a look offline, that's probably easiest.
Bart Brinckman: Okay. No patch support. Like we we think like actually patching SDF models or having an API that allows you to patch SDF models may be a little bit overkill. We have a put that allows you to update them. So basically kind of it it's a, yeah, kind of a full patch, right? But we thought, you know, actually patching the SDF model would be a little bit overkill. So we do have a put. So
Ari Keränen: Yeah, and I think maybe we need a bit of extra consideration how to do the patching that is goes way beyond the NIPC draft. But maybe what could be useful if we later on define how to do that, that NIPC could simply adopt that if if the server decides chooses to support that. Um, so it could be I don't know is it worth saying here, um if patch is later defined, you know, do the right thing. But but that it's not forbidden to do patch. Maybe that the wording in the spec is such that future just doing patch would be possible and then if the server doesn't support it, it just says "yeah, can't do".
Carsten Bormann: Yeah from implementation point of view we have some low hanging fruit here because we already have to have a merge patch implementation to implement SDF in the first place. Um, so it should be very easy to do a merge patch support. So SDF-ref is based on merge patch. So that would be simple to do. but of course I agree with Bart if we don't need it we shouldn't specify it now but we should make clear that patch plus the right media type is something that very much fits here.
Bart Brinckman: Okay. We can we can add that to the text.
Lorenzo Corneo: Great.
Bart Brinckman: and then event and action creation returns an instance ID in the location header.
Rohit Mohan: Yeah, this is saying that we are returning it only in the location error and not in the body. We don't return a body for these APIs which I think was intentional. Um because we already have it in the location header.
Bart Brinckman: So Ari, what's your feedback here? because I think this is probably fine. Um yeah.
Ari Keränen: Yeah, I I think this is probably fine. Um yeah. Yeah I I think it's it's okay. It it's more of I mean it's just one of those implementation choices that, you know, keeping payloads clean versus slightly easier parsing, and I think the decision you have is is good.
Bart Brinckman: Yeah. 16 is a typo, the disable should be enable. So we fixed that. CBOR for pub-sub but JSON for REST. Um we actually already discussed this and we actually added some text in the in the draft as well. I guess Claude missed that explanation, but it's already it should be already in there. No versioning. and this is exactly the reason we picked CBOR because we would we have a built-in schema and we don't need a version field. So I I don't know if and you know Carsten or Ari if you have any comments on that but this seems like it's not needed. Failure response fields are all optional in CDDL, they shouldn't be. So we fixed this. So this was a mistake in the CDDL. The pros implies optional or multiple but it says one of the following. So it's not multiple, it's one.
Rohit Mohan: Yeah, I'm not sure why this was flagged because the paragraph on line 333 is correct.
Ari Keränen: Can we pause here for a second and maybe Carsten maybe this is Claude having a misunderstanding.
Carsten Bormann: So what is what is Bart saying? Claude saying that the choice is a choice.
Bart Brinckman: No, Claude is saying that the text implies that there's you can choose non or multiple and the CDDL says it's exactly one and but the text also says it's one, so.
Carsten Bormann: Good. Okay, so we have to teach Claude a little bit more about CDDL.
Rohit Mohan: Actually I think Claude also got the CDDL correct. so I'm not sure what it's complaining about the text.
Carsten Bormann: So the the paragraph on line 333 is correct. Now how would we address this? I mean, what is to be addressed about that.
Bart Brinckman: I don't know, it we say it's maybe maybe we include the keyword MUST you know or something so that it's more clear, but I think the text is clear.
Carsten Bormann: Do we expect do we envision a later extension that allows you to do what 333 says, receive events via both webhook and MQTT.
Bart Brinckman: Yeah, I don't I mean for a specific you know for a specific data app no. right? because you can still you can do it, right? you could say this event I'm going to configure two different data apps for it, one using MQTT and one using webhook. that's possible, right? but not in the same data app definition.
Carsten Bormann: Thanks.
Ari Keränen: Yeah, this seems to be addressed then. Thanks.
Bart Brinckman: Data subscription subscription field is required in CDL but data is optional. Yeah, some subscriptions don't require data. Like for example a connection status. Is that okay or should we add some text to that to?
Carsten Bormann: So what is the value of of the name subscription.
Rohit Mohan: It it's a choice group. So the choice could also be empty.
Rohit Mohan: No, it's not a voluntary choice, it's actually saying the data field in line 346, it's saying that that is marked as optional, but that is intentional because it depends on the type of 350 subscription whether the data will be present or not.
Carsten Bormann: Okay.
Bart Brinckman: subscription is not optional, it's data is optional. Okay. This one is still marked as TBD but I think Rohit we discussed this right? so the
Rohit Mohan: yeah, I don't think I I don't know if I fixed it, I need to check. But okay, so the issue with this, maybe this is something we should discuss. The timestamp there is a timestamp field in the subscription message that we put it as float and it's saying that instead of using float we should use the tag type which is tag 1 which I think is a timestamp field which is suitable for you know the timestamp. I think the issue that we ran into when we implemented this is the library that we were using for the CBOR serialization didn't support tag fields. So that's why I think we just put it as float initially. So I guess we can change it to say timestamp can be a time or should it be a choice where it's time or a number.
Carsten Bormann: Right, but you say we don't need the tag. Well the information that this is a epoch based timestamp is in the data definition, is in the CDDL. So you would say something like tilde-time to to actually say that this is what what it is.
Rohit Mohan: Right, but you say we don't need the tag?
Carsten Bormann: Now I'm shooting myself in the foot because if you say tilde-time then you allow integer there. Yes, which maybe we don't want to do. I have don't have a strong opinion on this, I just I'm just trying to make sure we express what we actually want to say. Well then I would just keep it at float then. Good.
Rohit Mohan: Sounds good. So the the text says that this is formatted like a the content of a tag 1.
Carsten Bormann: Okay. The important point here is that people know this is in seconds from 1970.
Rohit Mohan: Right, but I think we can Yeah, we do have that I think in the text and I think in the CDDL have added it as a comment because I didn't know how else to add it.
Carsten Bormann: Good. So it's good if the text just points to tag 1 because that has a rigorous definition.
Rohit Mohan: Okay. Yeah I think we can add that. Yeah, but not change the CDL then.
Carsten Bormann: Yeah, so we all hope that we won't have another leap second, so I think we can ignore the little problem that that this creates. Okay.
Bart Brinckman: then 23 the action CDDL has an optional action field.
Rohit Mohan: yeah, it shouldn't be optional, it should be mandatory, so we fixed that.
Bart Brinckman: trigger CDDL uses SDF reference with SDF name but pros SDF name. So we fixed that one as well. That was also a inconsistency. BLE BLE flag enum is incomplete.
Rohit Mohan: so we we did indicate right without response as two different types. the other two are not in the BLE spec so I'm not sure why it made there isn't like a broadcast flag but yeah, we did add the indicator and right without response.
Ari Keränen: Sounds good. probably hallucination.
Bart Brinckman: I mean it's probably anticipating the next BLE spec.
Ari Keränen: Maybe knows more than we do. Yeah.
Bart Brinckman: 26 unsupported URI scheme error type missing from CDDL.
Rohit Mohan: yeah, this this error was missing in the CDDL but it was there in the IANA registration and other error sections. I think there are a few other error types that were either missing in one of these sections or the other, so we fixed all of those.
Bart Brinckman: connection CDDL uses protocol info service map not named key. what is this again?
Rohit Mohan: Oh yes, so the protocol info service map we support like connection one or can also be like a broadcast specific protocol info.
Bart Brinckman: That's the service map, right?
Rohit Mohan: That's used only in the extension.
Bart Brinckman: Do we have protocol info broadcast?
Rohit Mohan: yes, we do have it in the CDDL but the API itself is an extension, so
Bart Brinckman: sorry?
Rohit Mohan: the API itself is an extension, but we do have this in the CDDL.
Bart Brinckman: it's never referenced by an API CDL but it's referenced by an extension. I think it's flagging it because we don't have a section for the extensions, it's only in the appendix. Yeah, I guess so because the extensions are or you know not in the spec, only in the appendix, so maybe maybe that's why it flagged it.
Ari Keränen: Okay, maybe it's good to double check if that was then an error or if it's actually not referenced. I guess it's good to double check that. Thanks.
Bart Brinckman: I think that's the case yeah because it's used in transmit and it's in the in the annex. But we'll double check it. Yeah, this was the other one that I mentioned, I think this was missing in one of the sections. These two error types was missing in I think it was in the CDDL and in the IANA registration, but it was missing in another table that we have in the draft. Yeah. Eli also raised an issue about this, so I'd fixed it as part of that. Actions require polling but could leverage existing pub-subs or callbacks. Actually this is a kind of a polling API, but the but it also supports callbacks, so it supports both. So it it says could leverage callbacks or pub-sub, but it does support callbacks but it also supports polling. and we did add retry after.
Ari Keränen: Okay, so pub-sub is actually supported then.
Bart Brinckman: Yeah. I mean I I think he probably read the text and isolation and said this is polling and but it also supports callbacks.
Ari Keränen: Okay, then maybe it's worth adding a one sentence pointer in that section if it's not obvious, that might also then not be obvious for other implementers. So no new normative text, just a FYI.
Bart Brinckman: Thanks. No list all endpoints for data app registrations. end points are really defined in skim, so you can list them there. So there is a list but it's in it's not in NIPC, it's in skim. and then trigger creation has no item potency mechanism. so we did add a problem type for a trigger already enabled. So we fixed that. That's it.
Lorenzo Corneo: Okay, very good. Thanks Bart. so I guess this was a useful exercise.
Bart Brinckman: Yes, it was, yeah.
Lorenzo Corneo: maybe for reference, could you post this markdown that you have here? I mean, you could either on the list or in the GitHub issues. You could remove the couple of issues that were clearly hallucinations and if you could add a bit more details where you said fixed. some of them it wasn't obvious how you fixed it. you told it today, but it wasn't clear just from the one word. Add like a half a sentence or sentence of how it was fixed. Then that would be perfect, then I could, you know, go through it and see that yeah, it all makes sense.
Bart Brinckman: Okay. We can we can take another look at this.
Ari Keränen: Very good. thanks.
Lorenzo Corneo: Thanks Bart. anything more? Do you also have some protocol mappings or
Bart Brinckman: Rohit, do you want to cover that?
Rohit Mohan: Yeah, for the SDF protocol map, we did push a new draft. Most of it I think is or I think all the changes were I think Carsten had a PR with like changes on how to do the folding and I don't think there was any other change in that. But there are a couple of open issues that I do have a fix but then I published the draft before I fixed it. So will probably push another draft maybe this week just to address those changes. And that's all for me. sorry, Ari.
Ari Keränen: sounds good. and and regarding the spec issues empty, actually Lorenzo wrote in the notes much better than I had. If you can put this whole content in the notes and then we can do even edit pass together. just copy-paste the contents you have there at the end of the notes of this session. will be rendered nicely and everything.
Lorenzo Corneo: Yeah, I'll make a section in the notes so that is also clear. We have four minutes left. Maybe time to schedule the next interim meeting. Bart, yes.
Bart Brinckman: Lorenzo, one more question. the like are we ready to move forward on these specs now? I feel like I I think I I want to kind of get the working group's thoughts on that.
Lorenzo Corneo: Yeah, I will discuss this with Michael, but do we have any opposition here? Ari.
Ari Keränen: No opposition. Maybe one thing that was still planning to do that didn't have a chance is to cross-ref with the Open API spec, the current spec, because I now only did with the CDDL. So there might come up some more issues, but I'll I'll let you know. Those should be simple issues to fix because I guess the Open API should be updated not the spec text.
Bart Brinckman: Yeah, so be yeah I'm hope yeah that those are all relatively simple minor I think.
Ari Keränen: Yep. Right. So maybe Ari if if you can commit to do this rather you know in a week let's say or or even less if possible.
Bart Brinckman: Or if anyone else has time, please go ahead.
Ari Keränen: Of course, of course, yeah. But I mean the draft is is in super good shape. I will discuss this with Michael as well of course I cannot...
Bart Brinckman: We can probably do this ourselves as well right? it's not a it's not a
Ari Keränen: yeah okay but then please also do that.
Bart Brinckman: Yeah. that's the fastest turn around. You guys you guys go ahead, tell Claude to implement the Open API spec and and your and standard draft and do an interop test. You'll find out.
Lorenzo Corneo: Exactly. So we can discuss this offline also Bart, but I think it is good to go. And then last thing, when do we have the next interim meeting? I propose 27th, May 27th. same time.
Carsten Bormann: so we will have AD feedback at some point. Yes. And I think we need to estimate when that will be. so we can discuss things in the interim.
Lorenzo Corneo: Right. So maybe I wait scheduling the next interim and then we take this offline on the mailing list perhaps?
Carsten Bormann: what do you think Carsten?
Carsten Bormann: Yeah, so we we have to schedule the interim two weeks before it happens. So yeah we we need to find out when we will actually submit and then we need to find out how long it will take until we have an AD review. And I think at the time we submit we can ask the the AD to provide a estimate when we will have a review so we can schedule the interim.
Lorenzo Corneo: Okay. Okay but then I I put it on hold and then once we push the button then we we ask AD about an estimate. Great. Okay, thanks. Just one last thing, what is the sentiment about meeting in Vienna? to have a meeting in Vienna?
Jungha Hong: Jungha and I cannot attend the meeting in Vienna.
Lorenzo Corneo: Okay, thank you. How about the others?
Jungha Hong: And how about why don't we do it 30 minutes late on the same day May meeting?
Lorenzo Corneo: yes, when we schedule it we we can do that, right. Thank you. Ari, Bart, Rohit, anyone.
Bart Brinckman: Yeah I I should be able to make Vienna.
Lorenzo Corneo: Okay.
Rohit Mohan: Yeah I might not be able to make it to Vienna.
Lorenzo Corneo: Okay. Ari, probably
Ari Keränen: I can probably make it but only in the beginning of the week. in the beginning, right I remember. so I need yeah I can only do a short meeting.
Lorenzo Corneo: Yes. Carsten?
Carsten Bormann: I will be there.
Lorenzo Corneo: Okay, okay. So I will be asking the same question other days. But we are one minute over time, so I thank you all for attending and bringing on great work. I'll ping you on the mailing list when we know more about the next interim. Thank you everyone and have a nice rest of the day. Bye-bye.
Ari Keränen: Thank you. Bye-bye.