Session Date/Time: 01 Oct 2026 12:00
[00:00:05] Thibault Meunier: Okay. Fantastic. Nice.
[00:00:09] Micke Nordin: I'm in the airport in Helsinki, so that's why it looks a little bit weird.
[00:00:16] Thibault Meunier: I mean, still looks quite okay. Sometime at the airport, I can't just have the camera facing up just so you don't see everything around.
[00:00:23] Micke Nordin: I got a silent pod here, so that's pretty nice.
[00:00:30] Thibault Meunier: Okay. Hopefully, we have others to join because I kind of mistaken... Misclicked when I, like, rescheduled the the like, the actual one and, like, scheduled it in U... UTC and CST. Like, kind of, like, messed up on that side.
[00:00:45] Micke Nordin: Yeah. I think people will join. Yeah. Anyway, just said p.
[00:00:57] Thibault Meunier: So did you say pay or did you say p?
[00:01:02] Micke Nordin: Giuseppe will have to answer himself, I think. Hello? Hello.
[00:01:10] Giuseppe Presti: I I disconnected. Sorry. Because it it didn't work on on on FESCO, then I had to disconnect, reconnect it. What was the question? How
[00:01:21] Micke Nordin: to pronounce your surname? Yes. Yes.
[00:01:30] Thibault Meunier: Giuseppe. Okay. So Giuseppe or Giuseppe?
[00:01:34] Giuseppe Presti: No. No. No. That would be very English kind of thing. But, okay, I I got anything. I mean, there are kind of ways to write also to miss typing. Typically, I and u swapped because in languages, g u is softer. So you say g, like... Or you say v, and the difference is very vague. But finally, I mean, this is... I'm used to many variants. So, Micke, I guess you are in some kind of corner in Helsinki.
[00:02:11] Micke Nordin: I'm in Helsinki Airport.
[00:02:14] Giuseppe Presti: Actually, the airport already. So it's already covered. They'll kick off anything else.
[00:02:17] Micke Nordin: Yes. So it ended with lunch today, and then I headed over here right away because my flight leaves about an hour after we are done. So I wanted to be inside of the security control and everything.
[00:02:32] Giuseppe Presti: Okay. Yes. I see. Yeah.
[00:02:36] Micke Nordin: But I met with Cuba, so he was... It sounded like he was quite sold on the idea of having Bologna be a remote location for IETf- Yes.... In Kuala Lumpur. So maybe we can have a huge
[00:02:54] Giuseppe Presti: meeting I've put it in the slides even though this is a kind of a side material, I totally agree with you, Thibault. So you run that part, but then I have this last slide about next year, and I wanted to put this idea forward. Right?
[00:03:09] Thibault Meunier: Yeah. Like that's what I've seen. Think I sent you an email reviewing the the, like, slides. There's a kind of, like, overlap. Like, that's also okay, I think. But I know. Like, the feeling that
[00:03:20] Giuseppe Presti: It's Yes.
[00:03:21] Micke Nordin: It seems to be
[00:03:22] Thibault Meunier: It's fine. I think we'll wait until five past the hour to see if, like, there are more people.
[00:03:29] Giuseppe Presti: Yes. If it stays What a reminder also on the on the matrix channel that we typically use just for... So then Cooper was there. That's why he came to Amsterdam only today. So I'm trying to join the two the two.
[00:03:53] Micke Nordin: Yeah. Kuba and Hugo was here.
[00:03:57] Giuseppe Presti: Mhmm. Yes.
[00:04:01] Micke Nordin: So we are building a large OCM federation in Europe, the European Open Science Cloud, and there are a lot of meetings happen... Happening now for that.
[00:04:16] Giuseppe Presti: Indeed.
[00:04:20] Micke Nordin: Here's Rasmus, at least.
[00:04:23] Giuseppe Presti: Yeah. Well, I told him to join, indeed. Then... Yeah. We'll also expect at least the next cloud people maybe or or even Richard. Don't know. Usual suspects that we meet.
[00:04:44] Micke Nordin: Yeah. I I was hoping I ping them too.
[00:05:14] Thibault Meunier: Okay. Give me, like, five minutes after the hour. I think we can start. Pre will go a bit faster given our synthesis. And we can also use, like, the opportunity to just discuss and, like, better prepare for, like, the next step just to ensure, like, the... And, like, more people engage down the line and the the the the thing is through here. Mandatory slide. I believe this is a nice EIF meeting. It's recorded. The participation is, like, covered by the Northwell. It's the same Northwell, not that that was, the meeting that we had in Vienna in person Mhmm. And for the previous interim that we had. And here, I think that we'll start after, like, this presentation. It's best to ensure that, like, you're muted and that your video are off when you're not speaking so that slides can be shown. So thanks, Giuseppe, for, like, acting upon that. And, yep, before you participate, you can, like... If you can state your name, like like, at the queue, and it seems we're, like like, rather small group. So that's something that should be rather easy to manage. The agendas that we have for today is... Well, the presentation of the agenda, which, like, we're going through, a document status. So, like, I will start by presenting at least, like, the status that we see based on, like, the activity that, like, happened on the list and on the document, and Giuseppe will continue. We will we will select some more some more updates on that. Then, Micke, you had two presentations that you wanted to go through and two items that you wanted to pro... To bring, which was, like, collection ID and, like, having more arrays. And then there's a distributed directory service, which Giuseppe wanted to discuss. Again, if we, like, want to discuss it here or, like, have some more discussion on the mailing list, that's like something which we can advise. And then finally, some time for discussion. I think, again, given, like, the number of participants at, like, which date, should be rather easy to adjust the agenda. It should be, like... Should some items require more time and some require a bit less time. Part of the discussion is also planning in terms of, like, what we want for IETf-one to seven. If we want to have, like, a meeting directly on-site, if we would prefer to have, like, an interim, which is more on European friendly hours ahead of the IETF or right after, and that's something which we can discuss during the discussion. Any agenda bashing before we continue? Okay. Doesn't seem like there's anything, so I will start with the document status. Well, this slide has grown since last last time we had it because we've adopted two new drafts, the MLS federated groups and the integration protocol draft, which are both now working group document on version zero. As far as I know, there's not been any modification to this document since they've been adopted. There was some modification during adoption to add a SREC model and some, like, slight precision which, like, came through the mailing list, and there has not been much discussion or, like, progress. These are, like, freshly adopted document, I think, as of September, if I'm not mistaken. And then on the main document that we have, there's been, like, one cut of... Like, one new version, which, like, kind of, like, tightened pulling some feedback, I think, the HTTP message signature language and, like, the the the the way it's integrated into a OCM. There's been some bigger rework of how notification work, and there's some slight introduction of, like, encryption, which has been added there. At least it's like what I had is that I think Giuseppe, in the next slide that, like, he will present, may have, like, a slightly more detailed list of capabilities which have changed. Any question, any comment based on that should be from office or other people. So if there are no comments here, I will just, like, change the slide and pass it to Giuseppe. Oh, actually, I haven't opened this. Not all good on my side. Okay. Thanks, Micke. I will pass it to Giuseppe so that we have, like, the slides. Hopefully, they've been imported. Yes. I have. Fantastic. So with with regards to, like, implementation status and next steps, let me give you control of the slides. Okay. And you should have controls. I will let you go through.
[00:10:16] Giuseppe Presti: Yes. So indeed, yes. Thanks, Thibault. So these are a bit of a continuation of what what you've shown just a moment ago. So this exactly as you put it... So this is the kind of just in a more graphical way exactly where we are with the different drafts. So in terms of a little bit more details, what I've done also was to update this list that I'm trying to keep for the contents, let's say. The notable change compared to the IATF working group meeting we had now two months ago, what... Even almost two and a half. Something like that is that the notifications is yellow is not red in the sense that the spec is there, and we have to work on the implementation. In fact, there is nothing in a way... Let's say, the spec work is pretty much completed, and there is there is now a matter of making sure that the spec is is actually sound. It's doing the right thing. And indeed, concerning that, I am anticipating something which is not yet fully decided. I know this is public being recorded, but I think it's safe to say it. And, anyway, if this doesn't happen, I'm saying in advance that this is not yet confirmed. But there is a likely chance to actually extend and continue the work that that has been funded by Sovereign Tech because the original project ended yesterday. It was until September, and they suggested that we can go until the end of the year. And if this is true, the plan would be to actually do the implementation so that then we can feedback to the spec. So we would do the implementation of notifications, then implementation of MLS, so the federated groups, what Micke developed in terms of spec, we will validate it so that we see if this is good. And, potentially, also this distributed directory service I will mention in the next talk. And so where are we now? Essentially, the idea would be before the end of the year, finish this work and refine the spec. Then there was also this point about security review. I didn't get an update from On Cloud yet after they offered it, like, many months ago. So I decided to engage the same security team despite an obvious kind of conflict of interest because I'm part of the the others group, let's say. But, okay, this is done by... Not by me. This is... There is a team that is doing... That that that is looking after security that's in, and they're also looking after the security of the EOS code send node because of this EOS initiative that Micke was mentioning before. So a little bit also in the context of what is coming up, and this is really recent. It's in this month and the next next... Well, last month, so September and the coming months, there is a little bit of of option to do this. So let's see what we get to with that. And then, again, it's polishing and reviewing the the spec. Question that I would have for Thibault is that... Actually, two questions. One is about the IETf-one twenty seven where we are not joining, so we might also decide today, for example, that we don't do we don't do any meeting there, or we do it hybrid to be seen. We might even decide more or less last minute to still have time. But, okay, last minute to not really because I know how busy it is to IETf agenda. But I'm open to to anything. So, Thibault, please let let us know what what are your thinking on that, in fact.
[00:14:24] Thibault Meunier: Yep. Happy to. Have a couple of questions on the side, but, like, that will be for the end of the presentation. Specifically for, like, like, 01/27, it's not uncommon for groups to schedule interim meeting. It could be, like, before or, like, after, like, around the, like, main week the IETf happens in person. And this could be, like, specifically for, like, the reason and, like, arguments mentioned, which could be that we do expect most of the participants to be remote anyway, and it would be, like, still... It's still valuable to meet, and I do think we will have to meet by the end of the year. And therefore, we'll have to plan for a meeting. The question is, like, do we want to have, like, the meeting and, like, have a room in person, like, with people joining to, like, provide, like, some feedback? Yeah.
[00:15:08] Giuseppe Presti: So I'm
[00:15:09] Thibault Meunier: trying to work an interim before after. I do think that's something which we'll have to discuss, like, Lisa. Mhmm. In terms of sharing, if you have any particular, like, should be, like, constraint or requirement for things to happen, like, on-site or during the IETF. This is something that, like, you can send an email towards. I think at the moment, it will really be more pragmatic in terms of, like, what foster participation given everyone is remote as well.
[00:15:43] Giuseppe Presti: Okay. Yeah. I see Micke saying also that it would be remote. I will also be remote. Like, I will, for sure, sign up for a remote participation. Okay. I mean, then possibly we can decide a little bit later whether it's really worth of it there or we do it as interim indeed, as you say. And then there is also this kind of soft deadline that that that is part of the mandate of the of the group when we chartered it... When the the charter was one year ago, we were saying, okay. We give us time until the end of the year to get to get the interim draft or drafts. Now it's plural, in fact. So it's... Was good to say one or more kind of ready, which I think we are more or less there. Now I wonder whether there is any anything special that we have to do at the working group level to say, okay. This is what we are. Possibly, it's going to be enough to to to show the the documents and and how they are. And last slide I have is a road map a little bit already looking after next year because, okay, then we have the the last call. So this exactly what I already presented at the last... At the ITF in person. And then adding... Okay. So this is a bit of a of a wild proposal, let me say, for the ITF one twenty eight. So the one that is scheduled for March. Because... So as Micke just mentioned, it just happens that we have our annual gathering of the... What we call the CC communities or the cloud sync and share storage community that, in a way, hosts the OCM project, we can say, exactly on the same week. So given that... K. This was... This is a bit unfortunate because this means that, typically, Micke, I guess, will go in person to to IETf-one twenty eight to Kuala Lumpur, and I will go in person to the to the c s three meeting, which takes place in Bologna next year. But then it would be super nice to have a... To explore the option to do this kind of hybrid meeting where we connect the entire c s three workshop, which is typically of the relevant ET participants. Of course, doing the full meeting, like, full, like, one hour meeting with the entire conference connected, this doesn't scale. But some... There there is also time to plan about something, but what they what they remind is some kind of relatively short intervention. It could be ten, fifteen minutes, twenty minutes, something of this kind, which fits the schedule of the c s three conference and fits into the the IETf meeting in the working group meeting and try to run something there. And they already see questions being raised. So... But I'm done. So please...
[00:18:51] Micke Nordin: Okay. So, yes, Micke Nordin. I have two points. So for the RFC last call, I would be in favor of targeting end of the year December for the core draft. But I think that we perhaps should leave OCM IP and OCM MLS to go further into the next year. So perhaps adding new milestones for those would be a good idea. And in Shenzhen, so IETF-one hundred twenty six, they were experimenting with having remote locations connecting to the conference via a room, and it worked really, really well. So I don't think we should rule out having a one hour shared meeting between two locations, so both Kuala Lumpur and Bologna. I think that would be a great idea. I'm very much in favor of that.
[00:20:00] Giuseppe Presti: Okay. Thank you, Micke. Then I see Richard also.
[00:20:06] Richard Freitag: Yes. Hi. Richard Freitag here. I'm part of the CS three organizing committee as well, and it is every week on the agenda that we will have this virtual IETF session. So we will make sure that the... Both the time slot fits, the technology fits, and that we can also have, as Micke proposed, a longer session with an integrated q and a. And usually, the attendance of the c s three is quite high, so it should probably be between fifty and seventy people then virtually meeting you at the IETF in Kuala Lumpur. So I'm also all in for this type of collaborative meeting.
[00:20:49] Thibault Meunier: Yep. I think it's Micke. Like, mentioned, that's something which Giuseppe has started experimenting with. Definitely something, like, I have to look exactly how to organize, and I like how that happens. So, like, I will reach out internally. It definitely seemed to be, like, one of the... Like, to get, like, actual, like, people to, like, deploy OCM and, like, our participant into, like, the the the community. That would help a lot, I think. So I will... Like, I would check that in terms of, like, how the remote hubs and, like, the actual slots would work within the IHF. What is, like, the whole technical baggage that, like, goes behind that? If there are some requirements for, like, different rooms and etcetera. So I will check, especially as, like, the the most time we can have to, like, organize that. The best we'll be prepared to to make that happen and ransom mostly.
[00:21:40] Giuseppe Presti: Okay. Very good. And with that, I'm done. So I'll pass back to you, Paul, on the next... Okay. Then we keep in touch, indeed. We have time in the... To prepare, so that's good.
[00:21:54] Thibault Meunier: Yes. Couple of questions ahead. I think
[00:21:57] Micke Nordin: I like
[00:21:57] Thibault Meunier: the presentation that you had. One comment which I think followed up from, like, the after, like, the previous IETF. I think for the draft, we will request an early review of the HTTP direct, right, to get, like, at least, like, early feedback within the spectrum like this in That's Yes. For, like, draft, but also for, like, as you mentioned on the slides of the well known registration, if, like, there's anything that, like, we need to change. Like, having that early would help.
[00:22:25] Giuseppe Presti: Indeed. So that indeed is still on me. Thanks for reminding that. So I will send the mail. Let's say, I wanted to wait a bit that draft is kind of stable enough, let's say, which I think it is at least the core... The main one, it is accepted what Micke also mentioned. So I will ask the to to have a first review ahead of the last call. For the well known... Actually, we did cross eventually market there at the at the ATF towards the end of the week. And they told us that there is no principal problem with with having OCM as the well known address. And, okay, we we can look into this later on. I mean, there is no strict urgency, but he didn't see absolutely any problem with with registering that.
[00:23:14] Thibault Meunier: Yes. For the HTTP directory review, given it's a working group document, that's something Lisa and I will, like, initiate. But that... That's
[00:23:23] Giuseppe Presti: something we can do.
[00:23:24] Thibault Meunier: Like, that's something which we'll do before, like like like, actual working group last call to have that early and get... Like, get that rolling.
[00:23:33] Giuseppe Presti: So you're offering to actually send yourself a a message to the httpd and then say, look, this is where where we are. Please have a first look, or do you prefer me to do to do so? No. I mean, if you do
[00:23:44] Thibault Meunier: Like, that's something which we will do. Okay. And then I had one other question. I think you mentioned at the beginning of the presentation that you were expecting to have more implementation now that the spec is stable. Do you have any kind of, like, expectation from, like, this implementation and when they would come? What are the changes do you expect for this implementation? And, like, would there be some kind of, like, feedback loop if, like, some issues are uncovered during implementation?
[00:24:13] Giuseppe Presti: Micke, do you want to answer?
[00:24:16] Micke Nordin: Yeah. So we are... We have proposed to the sovereign tech agency that we ourselves do some work. So then we will have immediate feedback. But I also know that two other open source projects are working on implementing OCM. So one is the FileSender project and the other is One Data. So I think you have had contact with One Data and I have had contact with One Data. So we will provide guidance for them and be involved there, but they will do development themselves. So that will also close the loop for feedback, I think, that we can immediately get some information.
[00:25:02] Giuseppe Presti: Even though I should add that for One Data, I had the chance to meet, that was, like, a week ago in one of those US created meetings, and he was telling me that he's looking for some funding and some project to do this in a in a way that is not just in the corner because because there is... He didn't do anything yet. So he would be very interested, but he's looking for seeking into some some...
[00:25:27] Micke Nordin: I think that has happened in the last week.
[00:25:31] Giuseppe Presti: Ah, so you have a better news than I do. Great. Fantastic.
[00:25:39] Thibault Meunier: Okay. Thank you. Richard?
[00:25:43] Richard Freitag: I think... Sorry. I think I just forgot to leave the queue earlier, so nothing to add here.
[00:25:52] Thibault Meunier: Okay. Fantastic. Yeah. I think that's it. And as well, like, I guess, on top of, like, implementation, we should have some feedback as you mentioned from, like, like, certain situation review, which we'll, like, we'll take a look and ideally provide some feedback as well. So this is... Like, that would be helpful. Okay. Without further ado, I simply move to, like, the first presentation that we have. Like, Micke, do you want to start with, like... So I've put collection ID before more arrays, which felt...
[00:26:23] Micke Nordin: It's it. That's fine. Yeah.
[00:26:25] Thibault Meunier: Okay. Okay. I'll do that.
[00:26:27] Micke Nordin: As you will see, I did not spend a lot of time creating these slides, but I wanted to just make sure that we have something to look at while we discuss. So, collection ID, it's an idea that came up, in the last weeks when I visited the Nextcloud community conference. So we have and my motivations for this differ a lot from perhaps what the Nextcloud people are thinking about. Perhaps they can use this, perhaps not. But I am thinking of this in the context of request to share. So one of the principal components of the European Open Science Cloud is repositories of open data. And they will announce their catalogs of datasets where people can go and download data. So you can imagine that repositories, like OpenAir or Swedish National Data Services or Senudo or something can put up their open catalog and you could click a button like open through OCM, which would create a request to share and then they would automatically provide the data and it would end up in your files. And in the request to share now, we have something which is called a share ID, which is the unique identifier for the resource rather than the provider ID that we have in a share, which is the unique identifier for a share. So I think share ID is not a great choice that ended up here for the name of this. And in the same way, it's quite confusing for people to know what the provider ID is in the share. But that's been there for a long time and I don't propose that we change the provider ID. But instead, we could change the share ID since request to share is not yet implemented anywhere, and we could call it a collection ID, a unique identifier for the resource. So when you send a request to share, you would attach a collection ID there. And I've just... The text is the same. It could be anything. It's just something to let you know what you are looking for. And in the share creation, we have the provider ID and we have share with and all of these things. And the idea that I want to propose now is that we also add the optional collection ID here. So imagine that you send out the request for share to someone and then you get the share back. How do you know that your request to share has been fulfilled? There's no way to tie the two together. So if we have a collection ID here, which can connect the request to share or the publicly available dataset, like an identifier of the resource itself rather than an identifier for the share, then you would be able to make UIs that show like these are my pending requests, these are my fulfilled requests and things like that that we cannot do today. And it would be a pretty simple change. It would be backwards compatible for everyone. It's just an extra field that you can use. And you can use it for a number of things. You could use it for request for share, but you could also use it to connect disjoint datasets like if you have one file in each in two different folders that somehow semantically connects. You could assign them a collection ID and you can send that in the share and then you would have some way of communicating that information. So one example of this could be that the collection ID could be you could go into a repository and you could do a search and the search results will receive its unique collection ID and then you can share that with your OCM server and that would describe uniquely the set of data that you have. So this is my proposal for collection ID and the use cases that I see for it, changing the name of the key in the request for share and adding an optional field in the share creation to allow you to do some pretty interesting things, I think. So I think I will stop there. And if anyone has any comments or questions, I'd be happy to do that now. No?
[00:32:36] Thibault Meunier: Hey. Yeah. So Thibault, taking my chair hat off and just, like, trying to like to read and understand like the proposed changes here. So the idea is that we would modify the the, like, the core OCM document so that there would be, like, a new field, which is collection ID, which I... Do you see depending on the slide, it's required. Sometimes it's optional, and so that's part of the question you're asking is, like, will it be required? Will it be optional? Or is it or is it depending on, like, it ends up?
[00:33:08] Micke Nordin: Exactly. So in the request for share, it is required. And in the share creation, it is optional. So you can have unsolicited shares. So I decide I want to share something with Thibault, then you don't need to have a collection ID. You can have it, but it's not necessary. But if it's in a response to a request for share, then you would need to have it.
[00:33:37] Thibault Meunier: Okay. So that means that at least for like... Like, linking back to like what Giuseppe mentioned before. This is a change that, like, would need to be propagated to, like, the various implementation that exist and the one that will follow down the line. Have we received some signal that, like, this would be something that this implementation need today?
[00:34:01] Micke Nordin: Yes. So so the idea where I started to think about this was in the context of the Nextcloud community conference. So Nextcloud is reworking their sharing API and making it much nicer. So it's not like the API... It's the internal API, like the code base API surface. So they they are creating a new share object which can have multiple things inside of it. And one way... So I don't think it's useful or a good idea to model this new type of share object in OCM even though I think they have some some good ideas. But if they had a field which could, which they could use like this, the collection ID, then they could reconstruct their share object on the other side using this ID. So that's one use case for Nextcloud that they would want to use it. And that's... So one one way which it could be used, but not perhaps the main use case which I am thinking about in the con... Context of request for share and repositories and things like this.
[00:35:28] Thibault Meunier: Okay. Thank you.
[00:35:33] Micke Nordin: Do have some comments, Giuseppe?
[00:35:37] Giuseppe Presti: Yes. So in per se, this does look bad. At least the way I perceived it was much worse than this, to be honest. But I'm not sure. Jokes apart. The story here is more like if this is optional, it means that you don't want to add any semantics about things like partial success or partial sharing, etcetera. It's completely advisory. So even in Nextcloud... How is the Nextcloud going to use this collection ID if you share a collection of... I mean, you have a collection of shares. So still, there would be multiple share payloads to be sent. Each of them is independent. Right? Each of them can fail. Yeah. And then then the receiver can make some use of this collection ID to kind of bind things together or may just ignore it, and that's it?
[00:36:37] Micke Nordin: Yes. So I I think we... You shouldn't talk to Kate at Nextcloud about this who is writing the actual implementation. I think the what I understood is that this would be useful for them. I think I made it pretty clear to them that I don't think there will be a support for reworking how shares work in OCM in any principal way. But this would still be in a way which would be useful for them. And I can see a lot of other use cases myself, which is why I am proposing it because it's useful and they can use it. And I think the next presentation that I will have about more arrays will also help them, but it's things that I think are useful for anyone and which is not hard to implement or make fit. So I started thinking about these questions about multiple shares tying things together, having like a way of following, the flow of of OCM. But it's... The result of the thinking is a bit, unrelated, but still useful, I think, to implementers, including Nextcloud. Yeah. Okay.
[00:38:20] Giuseppe Presti: No. That... Yeah. That makes sense. And one more thing to come back to what Thibault actually mentioned. I mean, he he underlined the kind of difference between the two. True that the request for share is still new, so we can do whatever we want. But it kind of feels a little bit asymmetric that there it is required. You know? I don't know. It would... So... Even though there you call it share ID, not collection ID. So it's more about of...
[00:38:48] Micke Nordin: So... No. No. So... Yeah. So exactly.
[00:38:50] Giuseppe Presti: So we...... Different. It's not really a collection ID in
[00:38:54] Micke Nordin: So so... No. So in the current specification, this is what we have. We have the share ID, and it's required, and it's the unique identifier for the resource. And what I'm proposing is that we rename the share ID to collection ID here. And then
[00:39:11] Giuseppe Presti: Okay. Yes.
[00:39:13] Micke Nordin: And then we can use
[00:39:14] Giuseppe Presti: Nobody uses it, and then we use that one instead of calling it share ID.
[00:39:18] Micke Nordin: Yeah. Because then you can also tie together a request for share with the share that is the result of the request. So I think, the... There are some legacy things in OCM which we need to be aware of, which is like it's we are very much focused on sharing files or folders. But I think maybe perhaps it would have been more useful to think in terms of datasets or things like this. And this, I think, provides a mechanism for building new and interesting things on top of OCM, which isn't exactly files or folders or so that's why I'm trying to make generalize something that can be useful in multiple places and perhaps be useful in ways that we have not yet thought about.
[00:40:18] Giuseppe Presti: Okay. Well, now I'm good. Good.
[00:40:24] Micke Nordin: So can you bring the the next pair of slides then, Thibault? Yep.
[00:40:30] Thibault Meunier: Was about to do that. Just want to change that you've... You you were done with these ones. Thanks for the presentation. So let me bring the next one back. I'm passing control, and it should be okay. Okay.
[00:40:45] Micke Nordin: Yes. Good. So this is related to this the same thing, like collections and multiple things. And in OCM, we are very much focused on scalars. We have like we have objects, but we don't have many arrays. We have tried to change that in some places. But for shares, for example, you can still only have a single recipient. You can only share a single resource. You can share multiple... The same resource with multiple different protocols, but you can't really send five different folders to the same recipient over one OCM message. And the same is for... There... There's no way where we can batch notifications. You can send invites to several people, and there are probably many more things like this. And if we were to prefer a race, then it would allow requests to be coalesced. We would reduce overhead. We could support more complex use cases, share several disjoint resources, have richer semantics that allow use cases we don't know about yet. And particularly, I think this is important in mandated envelopes where you can't really build something on your own through the registries because you would need to conform to the same envelope. And I think this is not an easy question to answer because it would be quite intrusive to go in and add, for example, the share with create that and make that an array or the payload for the share, make that an array of several shares. So I don't think that we should necessarily do that. But one thing that we could do, which I think is very simple and easy to implement, is to allow the JSON payloads themselves to our endpoints to be arrays. So you could expose a new capability, so perhaps we could call it accept arrays, which would mean that instead of only accepting single shares to the share endpoint or single notifications to the notification endpoint, you could send multiple objects inside of an array to those endpoints. And that would be pretty simple to implement. You would only need... If you notice that the object comes in, it's an array, then you can loop through the array and process all of the objects inside of the array, which would be completely standard OCM objects that you already know how to process. So it's like a five minute thing that you could implement. And in that case, you could build much richer UIs where you could go in and select multiple resources and send them to a person or you could have multiple recipients, which could be expressed in this way. Yes. So that's basically my pitch. I don't think we should make any intrusive changes to the formats that we already use. We shouldn't do any backwards compatible breaking changes. But I do think that we could expose a new capability, which means that you can accept a JSON document that is an array of already supported and known payloads. And that would allow you to do batching and provide richer semantics and be... Make it possible to build nicer UIs. So, yes, that's all I wanted to say there. Yep. Giuseppe?
[00:45:38] Giuseppe Presti: It's okay. You have yourself in the queue for her, but okay. Let's say the... Then the complicated part of this is... I mean, I kind of see the general principle. Yes. Then indeed, doing invasive changes and if we don't really see the advantage... Let's say, the way I see it is that the coalescing requests, I don't see the cost in in the reducing of overhead. I rather see the cost in the in the... Complicifying the implementation because then we'll have to also do a little bit like the profile where you have the multistatus response. Then you would have to acknowledge that you got all of this list of things, and and you have to process each of them. And one may fail, one may go through, one may be refused or something. The thing is, in the end of the day, this is... We never ever... At least until now, we don't have a batching driven by use cases where you have tens or hundreds of thousands of of requests to be processed in batch. So the simplest possible batching that is I just send all of the requests one after the other, and I let the recipient process them, would still work. So I don't know. I have the impression that it's kind of not worth the the effort. Or maybe it is worth in some very specific places, but for example, I will not do it on the recipient. Like, if I have multiple recipients, I want to see one share per recipient. Recipients may be single users, may be groups, may be federations, and each of them requires, in a way, different processing. The cost of grouping everything together and then, anyway, on the server, I had to take each of them and then dispatch internally because I have to handle this logic anyway. But I would prefer this to be done. Like, I have multiple requests, and I already have the router on the server side to actually take each single payload and deal with it. And it's it's it's one atomic transaction, which can either go... Succeed or fail, and that's it. And this does interfere with the with the rest. So, yeah, I mean, in this approximation, I really see this as a very limited thing in in some places. Typically, collection ID that that you can correlate across multiple requests, this is nice. I bring also to the attention on... Rasmus put in the comments that indeed we are also working with data commons. And there, the principal datasets that contain multiple objects is kind of very, very typical. So, actually, it it beats... It fits very nicely. Grouping the processing is something that I consider too too expensive and not worth it. This is the part that I...
[00:48:36] Micke Nordin: Yeah. I think this is a fair... I can see, for instance, that it would make sense for notifications where you're not really giving a lot of answers. But for shares, it may be hard to implement. You're right, we will need to process them all and then reply like with a collection of responses for each of them. So yeah, I think that's a fair fair criticism.
[00:49:06] Giuseppe Presti: Yeah. True. The notifications are a bit cheaper, possibly. Yeah. And there could be there could be cases where batching them, but it could make sense. Please, I...
[00:49:14] Micke Nordin: I think for myself, then I will proceed with creating a PR for collection ID. But we can, yeah, leave this with the arrays on the on the back burner maybe. I will not proceed with immediately at least because I I think this is a valid criticism.
[00:49:41] Giuseppe Presti: Okay. I don't have anything else.
[00:49:48] Thibault Meunier: Any other question? Okay. Thank you for the presentation, Micke. And like actually the two presentation was probably like even just like opening the threads on list. Asking this is the first time that the topic are discussed with your group. So like that might be useful as well. On that. So the last presentation that we have is by Giuseppe, Distributed Directory Service. So I will pass, like, present the slide and pass the call to you.
[00:50:22] Giuseppe Presti: Mhmm. Thank you.
[00:50:24] Thibault Meunier: Here we go. And now you should have control on that, the floor
[00:50:29] Giuseppe Presti: is yours. Yes. Thank you. So... Okay. This this is something that was born very recently. And, actually, I take the suggestion from Thibault. I should bring this to the list so that we can expand a bit to a minute. All of those topics are worth a trade in the in the list, absolutely. So here, the context is that we did already describe what we call a directory service already one year ago, a bit before even the the working group was established. And the context was the US symposium and the fact that we are bringing up the US Federation, etcetera. Now this effort is restarting again, but there, I saw... We saw a little bit of limitation of this service being completely centralized, which goes a little bit... It's a little bit at odd compared to the rest of Centimeters, which is completely distributed. So to me, the the issues are indeed that the service is centralized. There is no provision in the specification to decide who has authority to change the content, so who is member of federation. Why somebody somebody... Some server can become a a member of federation or should be ejected, for example. So we have it. It's actually in operation. And as I say, we are actually sharing a JSON file and where some of us, we have edit rights to add to add the servers. But, of course, it's a it's a little bit of a precolonial for the moment. So the idea is to go distribute it, accepted like everything else is in OCM. I have finalized a put request, an hour before the meeting, so I I don't expect anyone to have read it. It was there, but in in a a draft mode. Now it's ready for review. And what this port request brings is a concept of every server... Micke already read it. K. Well, there were a couple of changes, like, the time an hour ago. Okay. The the biggest part was already there for for some days. So the idea is that, essentially, every server exposes what it knows about the federation of federations it's part of. And there are two models to support the way to spread this information. One that I called the peer announced. Every peer, every server can say... Can notify another server. Okay. I'm part of your federation or or you are now part of my federation, this kind of exchange. And this can happen because... So even today, how do we know... How is server a get to know that server b exists in the first place? For the moment, the only way is that there is an invitation coming from a user at b that got invited by a user from a. This user accepts it, so we get the invite accepted at all on server a. So server a knows about server b because there are two users that know each other. And this could already be a way to say, okay. Maybe we can raise the trust level, like, if the administrator or server a can say, okay. Server b is a server that I trust. I consider it part of of my federation. Or server a knows about a list of servers because this is preconfigured. This is a little bit what we do today. Of course, this model is eventually consistent, and it's not guaranteed to be always consistent at all times. And then another model is based on the MLS work, what what was already put in forward for using this OCM MLS protocol. And there, it's actually simple. And this is that the idea is simply to create a federated group where the leads are the servers, not the people. And then we reuse exactly all the concepts. Everything is the same. One point that I want to stress is the fact that the decision about whether a server is trustworthy and then goes into the federation belongs to the local administrator. There is no automation there. So this is really like... I mean, in the end, it's all about all about trust and policies. So a server can also decide to accept anybody, any server without any any vetoing, let's say. But, typically, for The US Federation, for example, there is even a full process to decide whether a node is member of the federation or not. So part of this would be reflected into the decision to admit a server into the federation... Into into the storage federation. So it's a little bit reflecting what they are doing at the higher level, let's say. Some details on what they've done and then the the discussion can go on, and then we'll go in the list for for more details. So there are two new notifications to tell about this. Right? I mean, server can tell another server I added you or I removed you. Then I'm using the federation as shared type in those notifications. So it's exactly like for the for the MLS based groups. So the only difference is indeed the fact that we have a group of services that have a group of people. But, otherwise, the concepts are all the same. So this is completely deliberate. And they say out loud that I used CloD to write a good part of the of the text with several prompts, and then I went for a... For my own review. And now it's ready for review. After I read all of it, I cleaned a number of things because I, honestly, I find Claude very often a little bit too verbose the way it produces text. But it got it right in the sense of by prompting on this kind of directions. Like, what I wanted was precisely reusing as much as possible what we have already built together. So they are more or less part in particular. So then it it it went in the right direction. Let's put it that way. So then it needed some amendments, but not not dramatically, let's say. And so this is what I have. Then, of course, I guess, some discussion. Okay. We can start a bit of discussion now here. I see Micke already ready.
[00:57:06] Micke Nordin: Yes. So I read it in the hour before this meeting. I haven't had time to redo anything of it before, so this should be hopefully the newest version. Oh, yes. So my first my first point is the middle bullet point here with federation as share type. I think there's a misunderstanding there because there are no shares involved. So we shouldn't be... Have to use any kind of share type because we are not using shares in this work of the federation. So I think the share type should move back and we need to define notification types, but we don't need a share type. And the other
[00:57:50] Giuseppe Presti: the share type or... So we have either share type or... What is the other? I mean, we have... One of the two is mandatory. And in fact, none of the two fits. So the closest close that share type is... It's called share type, which is also a misnomer, but it's the the recipient somehow.
[00:58:07] Micke Nordin: Yeah. So the recipient... Yeah. Yeah. And I think the... In general, the... It is a little bit of a problem that we are mixing federation to move two different things. So maybe we should take another round to think about how we can clarify. And we're using the same mechanism of establishing the group. So in that sense, it is a federation, but it's also higher level concept, which is different from a federated group. So using the same word in the text makes it a little bit confusing, but I'm not really sure how we should fix it and I will do a proper review of the PR and maybe I can come up with some improvements myself. But that was just, yeah, what I was thinking. And then the other part, which I have a criticism, I mean, in general, I think this is a very good idea. I think we should proceed with this. But there are I'm now bringing up the points where which I think there are some level of contention. So it's not to say that I'm critical of the proposal, it's just that I think that there are some parts which we need to look at. And the one thing which I find strange in the peer announced part is that we don't really need to advertise a document at all. We use notifications to establish the who are part of the federation, it will become eventually consistent. But advertising an endpoint with the peers in the federation, there are no real consumers of this data. They already know it. So why do we need to announce it? It's It feels like a leftover of the old third party thing. So either we keep the third party as a third option where we have the signed payload with everything and you can use that And you have the trust coming from the key, which is has been used to sign the thing. Or we have peer announced and cryptographically secure And then we just remove the document on the JSON endpoint because this could be some internal data format that you store in your EFSS. You don't really need to advertise it to anyone because there are no consumers of it. Thanks. I agree.
[01:00:44] Giuseppe Presti: You are absolutely right. Actually, we can simplify this part because, eventually, even in the peer in the peer announced model, you just list and hold the notifications and you build your list. But we know for sure that everybody knows the same list.
[01:00:58] Micke Nordin: Yes.
[01:00:59] Giuseppe Presti: Except for, of course, the people have been... Service being down or something like that. But before that, you need MLAs. You have the Yeah.
[01:01:06] Micke Nordin: Guarantee. Yes.
[01:01:07] Giuseppe Presti: No. I I see that. Yes. Absolutely. It's a leftover of the fact that we do have this thing at the moment, but it's
[01:01:13] Micke Nordin: Yes.
[01:01:14] Giuseppe Presti: I think we can drop it completely.
[01:01:15] Micke Nordin: Yes.
[01:01:16] Giuseppe Presti: I'll be honest.
[01:01:16] Micke Nordin: Good.
[01:01:17] Giuseppe Presti: And, Thibault, also as
[01:01:21] Thibault Meunier: Okay. Just closing. Like, think meeting one thing, I think on this one, just skimmed like with this PR. I think one thing which is worth considering is we approaching, like, if we'd like to submit the document by the end of the year is this change also relies on some more reference of OCM MLS, which is still a working group document. In in order to submit our document, we need to have more or less stable dependencies, and OCM MLS and OCM IP will not be that. So maybe if it makes sense to bring that... Instead of bringing it from the appendix to the main document, bring it to, like, a second document that, like, would be able to go, like, more at length and be able to evolve along with OCM MLS. That might be an idea as well. Again, not sure which one is the best idea, but just want to to raise that as we need to submit the document by.
[01:02:18] Micke Nordin: I think we could bring it into OCM MLS itself if we want to.
[01:02:25] Giuseppe Presti: We could also look into that. Yes. Okay. We would have to change a little bit the title or the or the the scope because at this point, the CMMLS will be a way to manage the federation of people and the federation of servers. It's it's the tool... The two aspects of the federation. Well, okay. Now that... As I say... I see this point
[01:02:46] Thibault Meunier: on, like, the direction as long as the group is happy with and etcetera. I just want to raise that this is something that we'll need to figure out by the end of the year if we're hoping to submit the document.
[01:02:57] Giuseppe Presti: Yep.
[01:02:59] Thibault Meunier: Okay. On that, think it's been... Even though, like, only a few people, it has been quite a productive meeting. One... So there's two actions item icing on the chairs, one of which is submit in the document for an early review by, like, the HTTP directorate, and then figure out for IETF one twenty eight how we can have the technical setup in the range for, like, a shared virtual room between, like, c s three meeting which is happening in Bologna and the IETf in Kuala Lumpur. So that's two action item on the chairs. I think on the office, specifically for, like, the the main OCM draft, as we're approaching, like, the milestone and, like, ideally have submission by the end of the year, entering the, like, the documents, like, ready to submit. And I I think that's something which will, like, work towards. That's it. Any last point before before we quit? No? Maybe shall I say
[01:04:12] Giuseppe Presti: just in case that... So for the Kuala Lumpur, let's look at the timetable. Right? And this is that we'll need... We'll have to be we have to take the time to......
[01:04:24] Thibault Meunier: In Poland and Poland so that it can be early in Bologna.
[01:04:27] Giuseppe Presti: Yeah. So we have... And even and even while in Bologna, we'll see how to arrange that. But... Okay. Possibly, if in this case, we can be a bit more flexible. But, typically, the way this history works is that the early part of the morning is, like, keynotes, plenary that take some some time., Micke. And then starting from, say, second part of the morning, it's the normal the normal part of the session. So it's... Then this really fits with a very late meeting on the on the other side. Okay. I think we have a... We have some all
[01:05:05] Thibault Meunier: the details. Just send an email to, like, ocmchairs@itf.org, and Okay. That would be
[01:05:11] Giuseppe Presti: a little
[01:05:11] Thibault Meunier: bit easier to
[01:05:12] Micke Nordin: to to exchange.
[01:05:14] Thibault Meunier: Okay. And then
[01:05:15] Giuseppe Presti: we'll talk to you about last
[01:05:17] Thibault Meunier: item? No? Okay. I'm there. Thanks all for participating, and, yeah, see you on the mailing list. Thanks.
[01:05:25] Giuseppe Presti: Thanks. Bye.