From W3C Wiki

Social Web Working Group Teleconference

06 Oct 2015

See also: IRC log


Arnaud, csarven, rhiaro, aaronpk, shanehudson, sandro, elf-pavlik, kevinmarks, wilkie, eprodrom, jasnell, ben_thatmustbeme, tantek


Approval of minutes from last week

<Arnaud> Approval of Minutes of 2015-09-29

Arnaud: any concerns or objections?

<tantek> +1 on minutes

<cwebber2> +1

<aaronpk> had a moment of panic that I forgot to post those last week

<Arnaud> RESOLVED: Approval of Minutes of 2015-09-29

<eprodrom> +1

Arnaud: hearing no objections, resolved approval of minutes

<tantek> Arnaud, if possible, please postpone my agenda items to second half of call - am going to switch locations to get on a landline.

Arnaud: We have changed our plans for next f2f, initially scheduled for TPAC but it is now in SF beginning of december

<tantek> thank you


Arnaud: There is a wiki page for this. Despite announcing this last week not many people have responded
... Please indicate on wiki if you plan to participate
... This will help with logistics
... The expectation is that tantek will host at Mozilla office in SF
... I understand there is a room for 12 people
... It's important to know if we will fit in there
... or if other plans need to be made
... so please do respond
... If you do'nt know for sure, say that on the wiki page
... Information is better than silence
... We should talk about WebEx. There have been issues, people have been having trouble calling in
... Evan mentioned that webex has a whole bunch of local numbers that peopel should be able to use in other parts of the world

<elf-pavlik> that sounds incorect

Arnaud: We are going to try to get you the link with the call in number
... elf has managed to join today using Hangouts. There are options, we just need to document them

<elf-pavlik> "The only call-in number supported by the MIT/WebEx instance is the one with the +1 country code: +1.617.324.0000"

Arnaud: Anything else anyone wants to add to this?

<cwebber2> now on call

Arnaud: We'll gather all the information and update the wiki page and copy it into future agendas so it's readily available

<aaronpk> elf-pavlik, it looks like the webex client can call you at any international number once you connect via the web client

AS 2.0

Arnaud: First one, update on publication
... We agreed to publish spec with a new license, unfotunately this has been a pain for james, the tooling has not been updated completely yet
... We have been working to get the publication tool updated to accommodate the new license. It's a chain of things, things keep breaking
... We're still working on it, it's not published yet, even though the document itself is read

jasnell: The core draft is published, I'm working on the vocabulary draft right now
... Hopefully that goes in the next minutes

<Loqi> Eprodrom made 1 edit to Socialwg/2015-10-06

<Loqi> Eprodrom made 1 edit to Socialwg/2015-12-01

Arnaud: Link to the published one?

<Loqi> Shudson made 1 edit to Socialwg/2015-12-01

<tsyesika> I'm finding the webex client isn't working for me either FWIW



jasnell: I'm working on the vocabulary one now, I'm getting some weird errors, trying to figure out now

Arnaud: I can confirm the core spec has been published, just put a link ^
... That's good news. Good chance we'll get the rest out.
... Any questions or comments?

eprodrom: Are we going to ahve any further problems, or will we do more monthly drafts as expected?

jasnell: assuming we get the process down it should be fine. The tools have been getting in the way. Once we've got through it once, then it should be much more regular

eprodrom: Great!

Arnaud: In fact, we're pioneering for everybody
... Once the tools are fixed, every other group can use that

<eprodrom> Great

<elf-pavlik> oh, true! in my case i need someone else to call me since i can't run webex client

Arnaud: We should talk about what's next for the specification
... Pushing towards CR
... There has been discussion and progress with text, but we require more than just a text document
... We need test suites and implementation plans
... People committing to implement the spec
... There is an exit criteria for CR, we invite the world to implement and gather implementation reports, usually using the test suite
... People can generate reports using the test suites against their implementation, send reports back, someone cosolidates the reports and we use this to justify that the spec can got to proposed rec
... So the two aspects here that are important are the test suite and the plans to implement
... Everybody knows we have had an effort made by IBM to start a test suite, but I was hoping there would be peopel who can help out and take it to the next step. We haven't seen that happen. It's unclear at this point who is planning to implement it
... We have been having discussion, we are starting to be uncomfortable with the situation


eprodrom: I'd like to discuss the timeframe that we're in right now. We've been discussing among chairs, but I put it on the proposed agenda items for f2f, that we'll be discussing the progress of AS2.0 and what our way forward is
... We'll need to make a decision if we've had enough progress with that by the f2f to justify going to CR
... If we can't justify it, we need to discuss alternatives
... Do we continue to work on it after the f2f, if ther'es progress we can postpone and make the decision later.
... Another is to decide not to publish AS2.0 as a CR. That would mean we could either not publish it at all, or we could publish it as a Note
... Means that it's kind of a suggestion/idea/best practice, but hasn't been throught he rigorous process a CR goes through
... I think that the things we're looking for by f2f are fluid, not a checklist:
... First is implementations
... We have two implementations, both by jasnell, JS and Java implementations
... Both open source implementations, but we need to have a few implemenations in order to go to CR
... The second thing is expressions of intent to implement
... Companies or existing projects that say yes we've reviewed the document and we intend to implement this
... Ideally it will be folks who have already AS1.0, they're the most likely to got o AS2.0
... And then the last thing that we need is a test suite
... This would ideally be something we could let implementors use on their own, that they could use to publish their implementation report
... Things to let peopel go forward

<jasnell> Vocabulary spec is published now as well...

eprodrom: We do have the test tool, the validator for producers

<elf-pavlik> jasnell++

eprodrom: IBM did that

<Loqi> jasnell has 30 karma

eprodrom: We need to define what the steps are with consumers
... How do we validate a consumer of activitystreams?]
... THat said, I think we have a lot to do
... There are some philosophical differences
... Some are of the opinion we are documenting the state of the industry. If we get to the f2f and there haven't been changes outside our group, our job is to represent that external reality and make our decision based on that
... There are others who feel that as a WG we can be pushing this forward and it seems that we have a few clear paths to go forward
... I think the test suite is something we can bring to the table
... Those who are planning to implement, free open source implenenations, will definitely move us forward
... And outreach to existing implemenations
... We have 2 months to go forward. For those interested in seeing it get to CR, we have work to do
... THis is my call to action to get us starting to do this work

Arnaud: What we're tryign to tell everybody is that we are concerned we don't see much activity on those axis. We need to look at this seroiusly and come to the f2f with expression of support or not
... So we know if we are moving forward or not, or what the alternatives are

<eprodrom> ?

cwebber: I was working on an AS2.0 representation library, and having worked on it it made me think that the most technical aspect of it is the optional requirement of JSON-LD. Otherwise mostly it's just a serialisation in JSON
... So that really makes me wonder what a test suite would look like
... We've discussed this before, nobody gave a clear answer
... There's not much to test unless you actually do something with it
... unless you submit it to some API or something

<Zakim> elf-pavlik, you wanted to ask cwebber2 if he used AS 2.0 extensibility

cwebber: otherwise i'ts just json objects structured in a specific way. What is there to actually test?

elf-pavlik: Question for chris: I wonder if you use some accessibility? You just use provided context, or you use other terms not in AS2 vocab?


cwebber: I'm not interested in talking about my own implementation for this part of the call. But I ended up hitting the point where I wanted to implement types, and if we did have the option to extend with JSON-LD I needed to write a JSON-LD expander, so I did

<elf-pavlik> cwebber2++

<Loqi> cwebber2 has 46 karma

cwebber: Is extension the thign that we're testing? What are we writing the test suit efor?

Arnaud: This is a valid question


eprodrom: I want to answer that. I'm not sure if we want to go into that in depth in thsi call. Maybe we could start developing a wiki page here ^

<hhalpin> Apologies guys, was getting the deal re WebEx from Wendy and W3C Management - have a brief update. TL;DR If group has consensus, moving to Mumble is OK if there is group consensus

eprodrom: for what we want
... Two sides to testing, one is to see if producers are producing valid output

<elf-pavlik> hhalpin++

<Loqi> hhalpin has 7 karma

eprodrom: THe second is to make sure consumers are 'understanding' what the input is
... I've been trying to look into some of the other test suites for other document formats
... I'd like to see us produce something ideally.. soem sort of test driver that produces correct output
... So we can test consumers. Somtehing like a commandline test driver so you can fire it at a library and let it parse a document and produce certain output

<elf-pavlik> possibly relevant:

eprodrom: So for example, ask what's the type of this activity, and it should emit the correct type
... What is the object of this activity, should emit the correct object. I think that might be ag ood way to do this test suite.
... However we should do this on the wiki

Arnaud: james, can you tell peopel what the validator JP developed, what kind of tests does it do?

jasnell: THe intent of the tests was basic validation fo the syntax
... Is it valid JSON? Is it valid JSON-LD? Are the values of the activitystreams valid?
... eg. are dates correct. Are the values expected.

<ben_thatmustbeme> i'm sure the validator will probably need to be updated as things have changed since then

jasnell: Really just a format validator as opposed to a test suite

Arnaud: That's what I expected

jasnell: If all we have is the data format, that's all we can test, is if it's valid


Arnaud: Except if there are constraints beyond the syntax that we want to test. But I don't think we have many of those.

<cwebber2> my phone just dropped :\

<cwebber2> stupid phone

jasnell: Evan's point about giving it those scenarios and test if they're valid, eg. Sally uploaded a photo, there are only ac ertain number of ways that can be encoded, we can test if that works properly

Arnaud: Anything else? Otherwise evan's suggestion is a good one. I inviet everyone who has an interest in this to follow on with a discussion [on the wiki]
... elf-pavlik, I believe you added this, links broken
... If there is a problem with the links, we don't need to use call time to discuss this

<cwebber2> eprodrom: thanks for that reply

<elf-pavlik> i didn't add it to agenda! i just fixed links after seeing it

Arnaud: Vocabulary
... elf-pavlik?

<Loqi> Eprodrom made 1 edit to Socialwg/Activity Streams test suite

elf-pavlik: The point I added about relevance to as2.0 vocabulary to social api, I would like to clarify if there's a strict requirement to use vocabulary in social api and federation, or if there will be another vocabulary
... I think we may have to wait to finalise the vocabularly until we know what we will use in the social api and federation
... I would like clarity on the approach. Separate vocabulary for api and federation, or we want to make sure to include everything in AS2.0 vocabulary?

eprodrom: I think this is a concern that we don't even have consensus that we're going to use JSON in our social api, much less that we're going to use AS2.0 or JSON-LD. I don't think this makes any sense. I think if we're going to use AS2.0 we need to just make it go forward rather than holding off
... I think of the spec that we have, by far the one we have farthest along is AS2.0
... I don't want to wait for social API to get AS2.0 out

<hhalpin> +1 eprodrom

<jasnell> +1 to what evan said

Arnaud: Any other reactions?

<cwebber2> +1 eprodrom

<tantek> I'm trying to read the IRC scrollback

<hhalpin> In particular, new vocabularies can be sent to an IG to be developed as needed.

<Shane_> +1

Arnaud: We were just talking about the challenges we are having with moving AS2.0 forward, if we tie it to something even less defined that makes it even harder

sandro: Is the question, are we committing the API to using AS2.0, or is it okay to design the API in such a way that it can use something other than AS2.0?

<tantek> great question sandro

<KevinMarks_> tantek - this is re

<tantek> I agree with sandro

sandro: Iw ould be uncomfortable with saying the API has to use *only* activitystreams

<tantek> I think AS2 compat is important, but not requiring AS2

sandro: Okay to accept activitystreams, but not *only*

<tantek> assuming we're moving forward with AS2

<ben_thatmustbeme> sandro, i think the original question was only the vocabulary match, not that the API use AS2

hhalpin: sandro are you comfortable with AS2?

sandro: Are implementations required to accept AS2.0, which I could live with, or required to *only* accept AS2, which I could not live with

hhaplin: Not *only*. Reasonable case to say it should accept at least AS2, but could also accept other things
... AS2 in addition to other things, like pure RDF or microformats

sandro: If it turns out that AS2 doesn't go to rec, we can't say you MUST accept AS2

hhalpin: I would be okay with that

eprodrom: Of the 3 candidates we put together, only of them uses AS2

<hhalpin> Just to ask, "Would anyone be uncomfortable to be accepting AS2? *with other syntaxes being possible to accept?"

eprodrom: I agree with harry that it feels that the charter is we have the social data syntax, and an api that uses that syntax. If we went with an api that does not use that syntax, it would be pretty remarkable, we would have to justify it
... I don't think that's a settled decision in this WG
... If we do not take AS2 to CR then we need to look at the purpose of this group and if we have a mandate to go forward with API and federation protocols that do not use an existing syntax

<hhalpin> I would say it should accept AS2 (assuming it is a Rec) and can accept other syntax choices, with the other two being pure unadulterated RDF and another being microformats

eprodrom: It's not 100% required, it's in not in requirements or user stories, but is strongly suggested yb going to CR with AS2
... Not making it exclusive, we want extensibility, but making a strong part of what the API is would be a good architectural decision

tantek: Certainly AS2 is the most mature of all the different technologies and charter areas that we've been pursuing. Like evan, I'm conerned that if we're not going to make progress with AS2 then we need to take a hard look at the purpose of this group
... On the other hand, regarding API candidates, one of the strong candidates which is micropub (strong on the basis of numerous deployed implementations interoperating clients and servers) does not reuqire AS2
... I think there is potential for compatibility with AS2
... One of the reasons I followed up with post-type-discovery is to explore areas for compatibility
... I'm not concerned with being bound to AS2. I'd rather have a working proven API than one that is bound to previous decisions
... But I"d like to see how we can make all these peices work together

Arnaud: It seems lik there is agreement that we shouldn't tie the two together
... It's still unclear what the protocol/API is going to be
... Best if it could leverage AS2 somehow, to which degree is less to be defined
... I think it would help to know more about what is oging on with social api before we go deeper into this

<cwebber2> I'm queued *for* the social API :)

Arnaud: We have several people working on the social api
... If the compromise really worked, maybe all these questions would be answered

cwebber: I think there are several things I'd like to update on that front
... One is about actual implementation

eprodrom: I don't want to move off this topic... elf's original proposal is that we hold off on publishing vocabulary until api and federation are better defined
... I'd like to take that to proposal

<tantek> I don't understand elf's proposal?

eprodrom: can we formalise this?

<tantek> are we stuck on updating AS WD?

tantek: what are we talking about not publishing?

<hhalpin> PROPOSAL: ActivityVocabulary not published until API and Federation are mature?

Arnaud: The question is, if the api is going to align with AS2, do we hold off on publishing AS2 vocab until they're better defined?

<hhalpin> The counter proposal would be

tantek: we have a new draft published right? So this is about the next draft?

<cwebber2> -1 on not publishing AS 2.0 until the other things are out

Arnaud: THe plan moving forward

<hhalpin> PROPOSAL: Publish ActivityVocabulary and AS2.0 independently of any progress on Social API and Federation.

Arnaud: Are we planning to publish vocab on it's own independant of status of API work, or want to work for API to solidify to publish

eprodrom: See harry's proposal ^

<cwebber2> +1 to publishing regardless

<tantek> keep publishing AS WDs - I really don't understand the question

<cwebber2> but

eprodrom: That's the question I'd like to address
... This has come up beofre, I'd like to come a decision on it

<elf-pavlik> -1 if we put API and Federated related terms in AS2.0 Vocabulary

hhaplin: Alternate proposal is to wait until we get API and federation more solid

<cwebber2> (+1 to understanding better about the format stuff, however this is a separate topic)

Arnaud: one proposal at a time

hhaplin: Which do we prefer, negative or positive?

<cwebber2> strongly prefer publishing the second one

<eprodrom> +1

<cwebber2> +1

<jasnell> +1 to hhalpin's

<hhalpin> PROPOSAL: Publish ActivityVocabulary and AS2.0 independently of any progress on Social API and Federation.

<ben_thatmustbeme> +1 to not linking publishing AS2 to progress of other parts

<tantek> PROPOSAL: keep publishing AS WDs (at least) once a month as previously agreed in the WG!

<csarven> +1

<hhalpin> +1

Arnaud: W're on the second: to publish without waiting


<elf-pavlik> -1 if we put API and Federated related terms in AS2.0 Vocabulary

<wilkie> +1

<cwebber2> it would be insane to throw out all that work

tantek: we're still taking working draft here?

<cwebber2> in. sane.

<tsyesika> +1

Arnaud: The plan moving forward
... Not talking about publishing anything right now, the plan moving forward

<cwebber2> I do think we should figure out if AS is a *requirement* for the API

<cwebber2> but

<tantek> +1 - this is the existing plan AFAIK!

Arnaud: a -1 from elf

<cwebber2> that doesn't stop us from doing activitystreams

<jasnell> the question is about whether or not AS 2.0 can move forward as a Note or CR independently of the API being done

Arnaud: Can you expand elf-pavlik?

elf-pavlik: Some of the terms are related to API and federation. Terms like I've listed on agenda page, like paging and audience targeting

<jasnell> given that we don't even have an API Editor's Draft, it would be insane to tie AS 2.0 progress to API progress.

elf-pavlik: I would like to clarify that if some of those terms are part of API or federation, if we want to publish AS2 we should remove terms that are not specific to modelling data

<jasnell> if the API needs additional terms, then it can define those as extensions to AS 2.0

<cwebber2> okay, we can iterate on that as we get closer to understanding that

<cwebber2> but really

elf-pavlik: If we want to publish it, I would make an issue about removing terms that are API specific

<Zakim> tantek, you wanted to discuss hypothetical federation concerns

<eprodrom> Sorry about interrupting cwebber2

<hhalpin> I'm ok with adding vocabs as extensions later when we get federation and API more mature, but not holding up AS2

tantek: I think that without a concrete federation proposal that has something that's workable/working, this discussion doesn't make any sense
... It's just stop-energy against AS2, I object to that
... elf, I think this is premature
... To object to update to AS2 is counterproductive
... If you really believe that federation requires that kind of vocabulary then go work on a federation proposal that uses that vocabularly

<elf-pavlik> I don't object updates but going to CR with API and Federation terms

tantek: It's a waste of time to say stop this other work because it *might* use this vocabulary

<cwebber2> okay, there's a valid kind of point toward's elf's point, I'll comment a bit towards that

<cwebber2> but

Arnaud: I don't think he's saying 'stop', just that we should synchronise work before CR

<cwebber2> I think it mustn't stop AS2

tantek: If he believes in that vocabulary requirement he should produce a draft that demonstrates that
... Saying deliverable might use it so lets wait to sync is unreasonable

Arnaud: we're very close to consensus, but not going to call it resolved to respect elf's objection
... if we get to a point where we get to CR, we might have t move forward to overrule elf's objection, as most of group is in favour
... Before we run out of time, move to social api

cwebber: I want to udpate on a couple of things
... The whole conversation about AS2.0 and whether that's linked to standard stuff.. when I was in Boston over the weekend I talked to people in MediaGoblin community and others in this group, and had a lot of thoughts

<tsyesika> I'd also like to see discussed the Webex/mumble issue hhalpin added to the agenda, I am only participating via text as I had WebEx issues

cwebber: I think elf is right, we do need to figure out if AS2.0 is linked, but that's a whole call in itself, so lets not do that this week
... But the other side, int erms of implementation, tsyesika is close to landing a massive rearchitecting of MediaGoblin so we can support federation

<elf-pavlik> tsyesika++

<Loqi> tsyesika has 14 karma

cwebber: THis has been holding this back, it's nearing actually working. This was all set up from the original plan of working towards pump API server to server stuff happening

<eprodrom> tsyesika++ !

cwebber: Confident in this happening by the end of the year

<Loqi> tsyesika has 15 karma

cwebber: Then we can move to AS2.0, which is then really not far way from ActivityPump
... That work is starting to get to the point where we're going to see some real results
... There's been some conversations in community about management, and ActivityPump version

<wilkie> I'll have to update my mediagoblin instance and play :)

cwebber: I've been working on implementaiton this summer, and got caught up yak-shaving, implementing JSON-LD
... Got a lot of interesting audience feedback at FSF talk this weekend
... Which I will email by the end of today
... I also talked to the person from OwnCloud (self hosted filesharing, calendaring, etc) which has a huge userbase
... Head of OwnCLoud wants to join this group
... It would be really big if we got federation working and agreed on a standard

<eprodrom> That's great news!

cwebber: He's going to go through the process of joining the group, I endorse him

<hhalpin> Great news re MediaGobliN!

cwebber: I did talk to others in the group, and will send an email

<sandro> cwebber2, do you know if the owncloud person was talking about joining as a W3C member or an IE?

<elf-pavlik> cwebber2++

<wilkie> so great

cwebber: So just wanted to update about MediaGoblin progress

<tantek> cwebber2++

<Shane_> That sounds great :)

<Loqi> cwebber2 has 47 karma

<Loqi> cwebber2 has 48 karma

<hhalpin> Definitely would support ownCloud joining

<tsyesika> cwebber2++

<Loqi> cwebber2 has 49 karma

Arnaud: You've been talking about federation API as if it's different from client API
... People have argued in the past that the distinction is meaningless
... You believe they're two different things?

cwebber: For MEdiaGoblin's implementation they have to be different. As an example implementation, there are two different steps

<eprodrom> I'm already on!

<Arnaud> yes, you are, and I know it :)

cwebber: It's true that there is a distinction between client-server and server-server, as we had to re-engineer stuff to do server-server
... However it's false becasue the mechanism of server-server and client-server look basically the same

<hhalpin> This has become a rather dialectical :)

cwebber: They're so linked

<hhalpin> Nonetheless, this is very interesting news to get from an implementer that supports the case for keeping one API.

cwebber: I think it would be dumb to seperate into two specs; it reads much more coherantly when you describe how these things work together
... Two sections, not two documents

<hhalpin> And one deliverable is *optional* BTW

Arnaud: what I think is important - the fact that there are two deliverables on the charter does not meaen we need two different documents
... Not a 1-1 mapping between deliverables and documents

<tsyesika> +1 for NOT splitting it into two documents

<hhalpin> I.e. federation was viewed as optional on purpose.

eprodrom: Two questions - you're implementing API and federation?

cwebber: Correct for now

eprodrom: Since we don't yet have social api/federation specified, just wanted to clarifiy.

<tantek> Arnaud, I'm hoping we at least have a few minutes to discuss (accept?) Post Type Discovery for issue 4 and action 35 (follow-up from last week)

<tsyesika> Arnaud: I'm also hoping we can discuss WebEx issues

eprodrom: Second question, for implementation, would be useful to have python library that can consume and produce AS2.0. Is that something that's part of these next steps for MediaGoblin, and something youc ould share?

<tsyesika> Arnaud: I and others have struggled joining over the last few months due to the changes

cwebber: I think that's possible. Need to talk to tsyesika. I'm optimistic. Was thinking when you said earlier that we do a commandline test suite, it might not be too hard to write that as a little python application. Something like that might end up happening.

<tantek> Arnaud - can we assign the WebEx issues to the chairs to handle offline?

cwebber: Let us talk about it and discuss next week

Arnaud: Defer to later
... Fight for the last few minutes as to waht we should talk about
... On WebEx, there is additional information we can add. We will take this offline. Look ofr information, we are aware there are challenges

hhalpin: I was just discussing this with Wendy Seltzer. Other groups have had this issue. No other group has resolved it successfully. But as long as the group has consensus on what software and everyone can use it, it is okay to swtich off webex

<cwebber2> sandro: I sent him an email about the process of Invited Expert

hhalpin: So if we want to swtich to Mumble, that's fine by w3c

<jasnell> dropping. have another call

Arnaud: We should try and make this work, not that I"m opposed to soemthing else, but we have addtional information we can try first

<cwebber2> sandro: if he should do something else, please let me know

<cwebber2> sandro: I'll send him an email and update him

Arnaud: tantek, what do you want to update us on?

<tantek> Post Type Discovery

tantek: I provided editors draft for review last week. Proposal is to accept post-type-discovery as an editors draft for WG
... You were given a week to review that, so that's the proposal
... If it's accepted, I'll move to w3c wiki and move to github for issues and discussion

<tantek> PROPOSAL accept as W3C editor's draft and use w3c wiki and github

Proposal: Accept post-type-discovery as an Editors draft for this WG

<aaronpk> there was quite a bit of feedback after the call last week, changes have been incorporated

tantek: After the call last time people asked for discussion/participation, spec has been updated since then based on feedback

Arnaud: Any objections?

<aaronpk> +1 to the proposal

<eprodrom> -1

<csarven> Code bloat?

<Shane_> I've not read it fully yet but it definitely sounds useful to me

Arnaud: evan?

<hhalpin> +1 but would be good to read it

<KevinMarks_> +1

eprodrom: What would be our goal for using this?

Arnaud: Next week we need to give this fair amount of time to get to the bottom of this

<elf-pavlik> -1 needs more discussion

Arnaud: Sorry tantek, we're not going to resolve this now
... Close the call on this

<ben_thatmustbeme> rhiaro++

<cwebber2> rhiaro++

Arnaud: Thanks everyone!