Session Date/Time: 21 Apr 2026 14:30
Sure, here is the complete verbatim transcript of the audio provided.
Giuseppe Presti: Hello, everyone.
Micke Nordin: Hello. Can you hear me, Giuseppe?
Giuseppe Presti: Yes, I can.
Micke Nordin: I don't know if it's you or me, but I can't hear anything. Ah, now I hear you. Good. Now, good. Does it sound okay? I'm on an unknown speaker. I'm in the office. It's all very new to me.
Thibault Meunier: So, hey, everyone. I'm trying to get control of the slides so we can start everything. Hope you're all doing well. Okay. It seems like I found the button. Um, can you all hear me?
Giuseppe Presti: Yeah.
Thibault Meunier: Okay. Um, maybe let's wait two more minutes until 35 and then we can start. But, yeah, that's it. Okay. So based on that, and given the normally participants should already know ITF policies before joining the meeting, and that we had this reminder, some tips for remote participant, which is, I guess, everyone today. Make sure your audio and video are off unless you're presenting. So, Mickey, you'll be presenting in a minute, so I think it's okay. And use a headset if you can. I'm not doing that, so apologies in advance for that. And during the discussion, you should be just state your name and use a queue. You have like a hand button to to join the queue and discuss here. On the agenda today, we have a couple of presentation by Micke, which is request for share, web app sharing and all the the the slides that you had. Um, maybe one question I have before we start, does anyone have a topic that they would like to add to the agenda, that they would like to mention or anything else?
Giuseppe Presti: Well, maybe I can. I was resetting my hand. So in the list, there was also something around the notification, which is mostly me and Madi. Madi could not participate because his network bandwidth still doesn't allow him to participate to the meeting, but I have some material that he shared with me.
Thibault Meunier: Oh, um, maybe I have not received it. Um, if you can send it again?
Giuseppe Presti: Very likely. Yeah, I can send them to... I was even thinking to share the screen directly because, yeah, I put together things only lately.
Micke Nordin: I can say that I'm very sorry for sending in five slide decks. We don't necessarily have to talk about all of them today. The one which is most important for me, I think, is the web app sharing because we will start implementation work on that soon. But I'm happy to move like any other to another interim if we want to have that, but, yeah, I'll go for as long as as you have patience with me and I'm happy to give a slot to Giuseppe to talk about notifications for for some of this.
Thibault Meunier: Okay. Thanks, Micke. So, Giuseppe, is 10 minutes okay for the presentation that you would like to make?
Giuseppe Presti: Yeah, even less probably.
Thibault Meunier: So, indeed, according to Micke, and given the kind of importance of topics, I wonder whether we should do like one, two, then I do my presentation and then we see how much time it takes for the rest because the other three topics are a little bit less in the critical path, let's say. What do you think? Yeah.
Micke Nordin: Yeah, it seems Micke's okay with that. I do agree that given that WebApp sharing is probably like the most important topic to discuss now, we go for the first two slots and Giuseppe, you can go after with a slot and we see at the end if there are some topics that we should follow up on the list or schedule another interim for. Sounds okay? Yeah. Okay. Good. So on that, in term of like document status, we had, you know, went from version 4 to from version the first version to version 4 of the only draft that we have adopted for Open Cloud Mesh. And I do think like part of like the discussion that we have today is covering some of the changes in future evolutions for that. And yeah, that's it. With that, without further ado, I will leave it to Micke for the first presentation. So I will just change the slide, look if I can do that. And Micke, I think you should be able to request control of the slides.
Micke Nordin: Yeah, I did.
Thibault Meunier: Okay. I just passed you control, so it's all for you.
Micke Nordin: Great. Yeah. So Request for Share is something that we have been talking a little bit about and there is a PR for this, PR 194. So I'm just going to go through a little bit what it's about and see if you all share my feeling that we should include this into the specification. So we want to have a new OCM endpoint that lets user request access to a resource rather than waiting for the owner to share it. So this one came up in the context of resource advertisement. So if you know about a resource that you want to access, you don't necessarily have to bug a person out of band, you could request it inside of OCM to get access to that share. So yeah, as I said, we only have the push model now, so the resource owner initiates sharing. There's no standard way for user to say, I know that this exists and I would like access to it. And this is something which is available in Dropbox or I believe OneDrive and other such services that you can request access to to files. So yeah, as I said, this is relevant in the context of resource discovery which we will talk about later. But in some way a user discovers a resource on a server. And then the person's OCM server sends a request for share to the other OCM server on behalf of the user, identifying the resource and the person who wants access. And then the resource owner gets notified and the resource owner can do a sharing gesture to indicate that they accept the request for share. And a standard share creation notification is sent back to the user who requested it. So I propose that we have a request body in JSON with the sender. So that's the OCM address of the resource owner. Share with the OCM address of the requesting user and a share ID, the unique identifier of the requested resource. So this is using the same nomenclature as we have going the other way. So it should be familiar for those who know about the anatomy of a share request. Um, I go to next page is not working. Can you...? Okay. Yes. And then we have the response codes. So for successfully received request, bad request, server does not support requesting shares and temporarily unavailable. And I want to put some security requirements around this to use TLS for all the required requests. Authentication via HTTP signatures. Um, and the flow is asynchronous. So the server accepts the request and when the resource owner logs in, then they can decide if they want to do this. So it belongs in a way together with resource discovery because that's the a way for users to find about resources. But it doesn't necessarily have to go with that specific resource discovery. You could imagine any number of ways that a resource owner can advertise the resources they have. They could put up a web page, they could send you an email. There could be many different things, broadcast it on television, whatever. So not necessarily together with resource discovery, but it makes a lot of sense in that context. And there's been some discussion on the PR if we want the field name to align with the provider ID. Do we want human readable paths in addition to opaque IDs? And do you think it's a useful concept overall? Should it move forward or do we want it to be... it's not a good fit for the specification? So that's all I had on this topic. And I would very much like to hear your thoughts on this.
Thibault Meunier: Yes, Giuseppe?
Giuseppe Presti: Well, yes, I can start just for breaking the ice also because we already had some discussion about about this. So for me, this is actually useful and it's a nice complement. Maybe not necessarily with the discovery part, but this by itself is useful. And we made already the example that it mimics in terms of UI what the big providers, say Google Drive, do whenever you get to know a link to a resource, but then you don't have access, you can say, okay, you don't have access, request access. And then the owner is notified. So it would be a nice way to have to extend this on this federation of of storage systems. And then out of those questions, whether it's human readable or not, not necessarily, but having parts or something very generic on how to identify a resource, a something that can be shared, I think would be useful because, yeah, just not to constrain this in any way. Um, the example is in in our own system, CERNBox, our Dropbox, we address files by their full path because this is how users are used to work and the fact that we disclose the full path is actually not a big deal. It's actually even a a desirable feature so that there is a kind of global namespace and everything is addressed by a potentially long path. So I may know about a given path and then I put it there and then this is how I can address a folder. But okay, in general I would see this as like the most generic way, I mean, the more generic the better.
Micke Nordin: Yeah, so yeah, so having a path as one of the possibilities, but like don't really specify the nature of the ID, but it could be a path.
Giuseppe Presti: Exactly, exactly. Yes. Meanwhile, I see that Madi indeed managed to connect. Thanks Lisa for sending this link. And good that even with the low bandwidth that currently you experience in Iran, you are actually online. Okay. Otherwise, I don't have any more comments.
Micke Nordin: Good. Yeah, I agree with that that point. But, yeah, good. Any other comments? No?
Thibault Meunier: Okay. Um, if no other comment, I will move to the next slide deck, which is Mickey, I think you you're still up and again I miss myself in term of buttons, hard to share a specific slide deck... okay. Here we go. And we go for like WebApp sharing, also before and that's something I forgot to ask, is anyone willing to take notes? We have pretty much automated notes taken and like the transcript like if someone is able to take notes, that would be ideal.
Michael Richardson: I'll log into the note taker and see what the things and see how I can help.
Thibault Meunier: Great. Okay. Micke, you have control. So yeah. Your time.
Micke Nordin: Move on to web app sharing. So currently we do have a share type which is web application, but it's not very well specified. It was did a proof of concept during the Science Mesh project of this. But it needs some work. And the current web app protocol only has three fields. It has the URI, view mode and shared secret. So the existing POC embedded credentials in the URL. So that's bad for security reasons. It exposes tokens in the browser history, server logs, headers, things like this. And there's no guidance on how to present remote apps to user. So should this be displayed in an iframe because in that case you need to have the correct CSP headers and things like this? Should it be a popup, a redirect? And I also want to define what a web app share is. So it's a resource together with the app to use it. So the the other way to think about a web app share is that from my server, I share, let's say Jupyter Hub with the remote server and they can open any kind of notebook they want, but this is practically hard to implement and it's more like a way of sharing resources, not like a compute resources or something like that, not really what what a user may want. It's more like my my server allows this other server to use my compute resources. It's not what a user may want to share. So the user would want to share a specific notebook together with the data and other things or they might want to share a a Word document to and allow the user to collaboratively edit the document, things like this. So what I'm proposing is that we add some web app embedding capabilities. So you advertise which presentation mode you support, so iframe, redirect, popup. And we enhance the protocol object with new fields. So permission, app name, app icon are new. And I propose that we reuse the view mode to become the presentation method. So currently view mode is similar to permission, but it has a little bit other semantics than the other permissions that we have for example with a WebDAV share. So you could have a... it has a view only mode which is similar to I guess a read only mode or where you can't download it, you can only display it. So I think it makes sense to keep the same terminology that we do in other type of shares, so to have permission and the view mode I think is a good name for the way you want to have it viewed, the mode to view it in, iframe, redirect or popup. And then add a layer of application access protocol. So how you do the token exchange and how you can gain access by posting the token in a secure way using a form post. So this is the same way that you do it in OIDC, for instance. So if you have a browser initiated navigation, you can't set authorization headers. A user can't click on a link and have bearer auth set on that request. Um, so but if you post form encoded post into either an iframe or a remote endpoint, that works and the credentials never appear in a URL. So that's my proposed way of solving this problem. So I am proposing that we add embedding capabilities into the capability in the discovery. So accept web app frame, accept web app redirect and accept web app popup. So this is the way that you can tell a remote server of what abilities you have. And the view mode would then match these ways of the capabilities that you have. And we reuse the web app share and SSH format permissions, so read, write, share. I think if we want we could have a view only or append some possible values to this array, but I think keeping the same format makes sense. And then to give some provisions to be able to present the application to a user in a good way. So have the human readable app name, maybe an icon to use for display in the UI. These are useful things to have for a web app so the user can click open in remote Collabora for instance with a fitting icon. Yeah, and then we have the token exchange. So what happens when you receive a web app share is that you exchange the shared secret for a bearer token by sending a request to the token endpoint, so using the code flow with HTTP signatures and then you deliver the access token via an HTML form post, so never in the it never enters the URL. And the target of the post depends on the view mode. Yes. So I made some integration examples. So WOPI based apps, so Collabora, OnlyOffice, Microsoft Office, this would work almost out of the box. This this is the way that WOPI uses a token to also authenticate. And for Jupyter Hub, you could do something similar, so you would need to share the notebook and the data as well as the runtime. So you would build a custom Jupyter Hub authenticator which extracts the token from the form post and validates it and maps it to a user identity and serves it to the notebook. So you could with a maybe like 30 lines of Python integrate Jupyter Hub using this flow because they have extendable authentication class that you could do. And there's also WOPI, in WOPI you have a post message API for life cycle events. So you can advertise to the app that the document is closed, the load status, focus and all of these things. So we can allow these sort of things and I don't propose that we prescribe our own protocol here, but we should be compatible with WOPI post messages. So this is how the end to end flow would work. So Alice shares a Collabora document with Bob. Bob clicks open in Collabora in the UI. The receiver posts the share secret to the sender's token endpoint. The sender returns an access token, so maybe 10 hour WOPI token is the standard for that. The receiver generates HTML with a form post into an iframe. The browser submits the form with access token in the body. The sender validates the token and returns the Collabora editor. Bob edits the document. Collabora calls sender's WOPI endpoints using the token. So the WOPI server itself will communicate with the sharing server to get the documents and you can have collaborative editing inside of your own EFSS. So the capability name... so I know for instance Giuseppe asked if it's a good idea to add three specific capabilities right away. I think it is. There's a case to be made for that because capabilities should describe what capabilities you have. And if this makes it possible to have a nice UI for for the user, then I think it's worth it. And are there other types of integration patterns that we should look at beyond WOPI and Jupyter Hub to see if this is the right shape of the protocol? So I'll hand it over to any questions if there are any.
Thibault Meunier: Simply a question in term of an icing that's been discussed in the chat in term of like should be accept, should be offer, like the terminology. Do you expect to like extend like this vocabulary down the line? Like for now like there's like iframe, redirect, popup, but do you expect like there would be other method down the line or like would these be fixed because of like the requirement you have for for the interoperability?
Micke Nordin: So I think these are the three major ways that a browser presents new documents now. So you either embed the document, you open it in a new window or you migrate away from the current window. So I think this has been stable for a while, so I don't see other type of view modes if you will. But you never know, but I do don't see the probability that there will come new ones soon anyway.
Thibault Meunier: Giuseppe?
Giuseppe Presti: Ah, Lisa, maybe you want to comment on...
Lisa Dusseault: Oh, yeah, sure. I was just suggesting the word "accept" seems to draw a parallel with the HTTP and WebDAV accept headers like accept range, etc. and if so the meaning of the verb is flipped. In all the accept headers the server accepts different requests from the client whereas in this case the server's offering different things.
Micke Nordin: No. So actually not. So this is telling... so you have a sending server, you have a resource that you want to send and you need to discover in what way you can present this resource to the user because in your share request you need to specify the view mode. So you're actually looking up what the receiving server is able to, what kind of shares they're able to accept.
Lisa Dusseault: So you... alright, I'll check who is saying what they accept but in any case if these words are already deployed it's no big deal. Thanks.
Giuseppe Presti: Indeed those words are not yet used, so we have a margin for adjusting things and already one I have two comments. One to answer and to reinforce what Mickey said. When we implemented this in CERNBox we only had the iframe and I tend to agree that the three possibilities are essentially what Mickey mentioned. I don't think we have more than that. I mean, this is pretty much all that exists. So coding them looks very reasonable. Then one comment that I would still make that I was thinking what I wrote myself in the in GitHub and this was not entirely clear even to me now that I read it, is I agree we need to expose those options. I mean, we need to have a way for the servers to negotiate what can be done in the most reasonable way. What I would rather do is those are properties of the protocol itself. So I wouldn't put them as capabilities which are kind of protocol agnostic. A capability is like I'm able to do code exchange for whatever protocol this is about or I'm able to do sign request. Rather this is very specific to web app. So as we advertise in the discovery I'm capable to serve web app shares, I think the best place where this belongs is really into the protocol itself because these are the details of the protocol, how the protocol is supposed to be used by the remote end. So it's really a matter of moving things around. And then whether to put accept something or or offer something why not simply put exactly the wording so iframe, redirect, popup? We can keep it simpler after all because it's already in the context of the protocol anyway. Because it's already... yeah. In fact you offered me the reason why it would be better to put it in the protocols. In the same... maybe I'm making things way too complex, but indeed we could have a server that is advertising both Collabora and Jupyter. And then by the way it is configured, Collabora can be embedded, Jupyter cannot. So then you want to have at the protocol level web app colon, then sub bullet Collabora colon, I can embed it, I can put it as an iframe whatever and then below Jupyter colon, I can only have it as an iframe. So those are all the details of how to structure the and this part of the structure is completely free for the moment because because this part so also to give a bit of extra context especially to the chairs, the only implementation we have at the moment which if you like I can also demonstrate with a video, it's not even running at the moment, was CERNBox three years ago where to make it simpler we only did the the iframe kind of of sharing and with the secret in the URL, which is not safe, this is totally acknowledged and that's why we're doing all of this work now. So there was there were no options, I mean, it was really just a redirect. So this is where I was thinking in this way as well. But my counterpoint to myself about having all of this is that if we need to do this kind of complex mediation between different apps, then we have not designed a very capable or generic web app sharing protocol. Because the only thing that you would need to be able to present any application is the ability to produce an iframe HTML which should work for any kind of remote resource. And all of the work to embed that would need to go into the sending server because they are the ones who need to do things with CSP headers and things like that to make it work. So my counterpoint would be that using this as the minimal common set for web apps would enable us to embed any kind of resource. We have exactly as much as we need to be able to do it for any type of resource. It shouldn't matter if it's Jupyter Hub or if it's Collabora or something else because in that case we should probably define different protocols for each of them. I don't know if you buy that argument or not.
Thibault Meunier: Maybe in like to to interrupt here. Um, I think we're getting over and it's like definitely like an active discussion here. I think it would be useful to like move like that discussion to the mailing list so there can be some like back and forth and like potentially external resources to be shared, I think Giuseppe mentioned for instance CERNBox running those codes three years ago that could also be like valuable discussion I think to to discuss as things that should also leave us some time now for Giuseppe to present the notification flow and then depending on like how this goes we see how much we can go into like the the the other slide decks that we have. Okay. So the notifications, here they are and Giuseppe I'm giving you control... puff, and you should have control on that.
Giuseppe Presti: Okay. Thanks. So indeed, actually thanks, Thibault. I can also send on the mailing list a link to this video because this was made public so then you can see how how it worked. Okay. So let's jump into notifications. As you see, I credited Madi for doing the research work. So this is I prepared the slide deck, but but most of the research was done actually by Madi and so this is a little bit just to also recap what was done in the in the first meeting, so also to give give a bit of a status update. So I would say things are improving, there is still a lot to a lot to do. And in particular, I still see this part is still requires work and the security also requires some work. Now, we're not talking about this today, this will be probably next meeting. We're talking about those specific items here that I'm that I'm mentioning that are specific to this notification. So what is what are we talking about? Those notifications are used or are specified at the moment to essentially to inform the remote side about a change or something that has happened on an existing share. So the typical case is Alice has shared a folder to Bob. Now, Bob wants to reshare it for example. This is a gesture that can be done. So Bob needs to inform actually Alice that this is something that he wants to do. So this is a notification. But also, we have learned actually that Nextcloud has implemented OCM notifications for example to work with their Talk system, which is a video conferencing system, so this is the way for exchanging participants or synchronizing the the chat. Um, so okay, this exists in there in the in the in the field, let's say. Now, in terms of specification what we have at the moment is very simple. It's just this. So we have a payload which looks like this where we have a notification type that can be one of those strings and nothing more in principle. Then you have the type of resource we are talking about, the identifier of the share, and then some generic payload, which is completely non-specified. So this is an object in Open API terms. So this can be really anything. How is this being used at the moment? So then we have a bit of a mix and there this is those are all the details of what Madi found out. So in Nextcloud this is how the acceptation of so when I share something to to a remote user, the remote user has the option to accept. And when they click accept, the sender gets a notification that the share was accepted. So this is how the payload looks like. So okay, this part is all very standard, fair enough. Then there's a message and there's also the share secret, which is a way to kind of associate so that this message is kind of self-contained. It contains the opaque ID of the share and the secret that was associated with the share initially. Okay. So far so good, but I will come back to that. Then what ownCloud implement instead is rather different because the notification part, so this the initial part is all the same, though this string is not in the spec. In the spec we have reshare, they use share. Whatever, this can be considered a bug in ownCloud. But then the interesting bit is that the payload of the notification is actually much richer. Now, in the spec we say that this is just an object. So this is according to spec is okay, except that if you send this to a Nextcloud, Nextcloud will not be able to parse it and vice versa. So at the moment the notifications are actually not interoperable. They cannot work between between the different implementations. And okay, what they did here they kind of replicate a little bit to this part, the protocol structure is actually very similar to the share call. So the OCM share endpoint. This is rather similar indeed. Okay. Then if we look at yet another case, so I mentioned that Nextcloud has this Talk application, which is this video conferencing system, and in in that case they do something completely different. Okay. Fair enough. So in this case you have a you have a different notification type, a special resource type, and then lots of details in this notification payload, which again is just an object. So this can be anything. Of course, this to work means that the other end will have to be able to parse this and understand what this is about. As far as I know, this only works between Nextcloud and Nextcloud. There is no no one else that implements this this protocol. So then we come to to the questions and and what to do next. Starting from the fact that the specification itself is relatively underspecified. So this is why we want to address this. So my proposal is the following. I think it's okay already to allow some kind of custom payload, such that applications like Talk, Nextcloud Talk or anything else can do whatever they want. But then at this point we need to have at least a way to expose this in the discovery endpoint. Could be a capability, for just to come back to the previous point. I mean, it must be known that a given endpoint supports Nextcloud Talk and then this comes with a with a set of notifications. What I would put in the spec even what we see at the moment is is at least those points and we need to agree on a minimal on a minimal common payload, which is pretty much what we already have. And probably can even relax the fact that we have a fixed list of notification types. I think we can relax this to allow applications to do whatever they want. At the end of the day, it's not compromising the interoperability once the application is advertised correctly. Then this I think is very important. Now that we have this exchange token flow so that the share secret is only used once to exchange a token and then all of the other interactions go with a short-lived bearer token, this must be clarified. Like you cannot use the share secret in notifications if the original share was created with a with exchange token requirement. So this we have to put it somewhere. Um, then we need to have some kind of agreement on how to name specific things. And I think it would be worth to at least specify the file sharing because this is the most commonly used application for that. I would go to the full details of specifying what to do when the protocol is WebDAV. If the protocol is something else, it's Nextcloud Talk, it's it's a web app Collabora whatever. Maybe we can leave without very detailed specification, but for the WebDAV protocol, that is the the most specified one, I think it makes sense to to have a proper specification, like fully out with full details. Now whether to what to put there? I'm really completely open. I'm not really having any strong opinion there. So this is an option and this is my last slide also and then this is really open for questions. You see that those three remain. They are at the moment the only three mandatory fields and everybody is respecting this. What is at stake if you like is really the content of this notification, which at the moment is a completely generic object, which indeed has opened the door for incompatibilities. So I stop here and I'm already open for questions. And I'm happy to go back in the slides for going to the examples. So yes Micke, probably you can already...
Micke Nordin: Yeah, I wrote in the chat, I was wondering if we should have an IANA registry for notifications so you can register your own type. We register a couple of the most common, the ones that we have now specified the notification part of it to, and then leave it open for other to use it. So for instance I'm, I want to reuse the notification endpoint for the MLS groups. Um, and this would be maybe good to be able to register things for compatibility when you develop something new.
Giuseppe Presti: Makes sense to me, yes. Now, I don't know the implications of going for a IANA registry. This maybe Thibault or Lisa may comment more. Definitely you know more than me.
Lisa Dusseault: Um, yeah, this certainly is possible to get an IANA registry for this kind of thing. Um, just has to be a part of a document and go through the working group and then it gets assigned. It it takes some time, but the initial values for the registry can be inside the document, which allows you to start using them I think it might allow you to start using them before the registry is actually created because you've like fixed them already. So I think there's a lot of possibilities we can work it.
Giuseppe Presti: Okay. Well, good to know. I mean, I mean, I can see the value if if really you have an application that the current example today is really this Nextcloud Talk that they did it and they are advertising it, they meaning the Nextcloud team, even in good faith like, ah, yeah, this is OCM compatible. Yeah, sure, but you just invented it without telling to anyone, and then we are reverse engineering what you did. You see, it's... yeah. I I we should do some thinking about whether that should be encouraged for long-term or say, you know, good for you for making it work, let's transition to the normal thing. Um, an IANA registry kind of encourages it for forever.
Giuseppe Presti: Yeah, that's a good point. Yeah.
Thibault Meunier: And maybe to add to what Lisa said, it's also like if for now like the set of notifications that you have is the one that you expect for the foreseeable future it might be okay then again if there's an update of the spec that maybe update the spec and expect everyone to follow, like register have an IANA registry at that time or or something like that. That's an option but it really depends on what are the expectation and what we want to do here. Mm-hmm. Definitely. Yeah. Okay. Any other question for Giuseppe? It doesn't seem there are any other question, so thanks Giuseppe for the presentation. Um, maybe a question. Micke, so you have I think two more presentation if I'm not mistaking. Um, do you want to have one very quick or should we have like the group to discuss in term of like next steps given we have five minutes left?
Micke Nordin: Um, yes, I don't know. Yeah, maybe we use the five minutes to discuss and we can push the the other ones to another interim perhaps. I think few of them at least would be good to discuss before Vienna.
Thibault Meunier: Did you want to start a thread for each on the list so that people can engage as well and yeah so that like exactly as you said we can like be a little more prepared for Vienna as well and yeah some more more general comments for folks if you have presentation or like topics that you have for the upcoming IETF in person in Vienna, feel free to like start the discussion on the list as soon as you're ready so that like there could be like be a valuable time to to discuss and engage directly on site. Okay, on that slightly overtime but thanks everyone for for your time and yeah let's keep the discussion going on the mailing list. On that, see you around. Thank you.
Giuseppe Presti: Very good. Thanks. Bye.
Thibault Meunier: Bye. Bye.