14:43:31 RRSAgent has joined #vcwg 14:43:31 logging to https://www.w3.org/2021/09/15-vcwg-irc 14:43:33 RRSAgent, make logs Public 14:43:34 please title this meeting ("meeting: ..."), ivan 14:43:53 Meeting: VC WG Telco 14:43:53 Chair: brent 14:43:53 Date: 2021-09-15 14:43:53 Agenda: https://www.w3.org/events/meetings/3dda3b2c-2ab9-4207-ab3f-3858ed9e1160/20210915T150000#agenda 14:43:53 ivan has changed the topic to: Meeting Agenda 2021-09-15: https://www.w3.org/events/meetings/3dda3b2c-2ab9-4207-ab3f-3858ed9e1160/20210915T150000#agenda 14:59:04 present+ ivan 14:59:09 present+ by_caballero 15:00:36 present+ cel 15:02:04 brent has joined #vcwg 15:02:08 present+ brent, manu, TallTed 15:02:34 present+ wayne 15:03:38 scribe+ 15:03:46 DavidC has joined #vcwg 15:03:51 present+ 15:04:24 rgrant has joined #vcwg 15:04:33 present+ 15:04:48 brent: Most of today will be looking at Pull Requests. We have pretty much until the end of month to get those in place. 15:04:59 present+ rgrant 15:05:13 present+ 15:05:28 brent: Welcome, rgrant 15:06:03 DavidC: Can we have a quick chat about the way to do the PRs. 15:06:06 Topic: VCWG at TPAC 15:06:11 brent: Yes, will fold that into the PR review. 15:06:23 brent: TPAC Meetings scheduled for 26th & 27th of October. 15:06:37 ... Tentatively no agenda set, but want to keep on calendar to be available should we need to be at that point. 15:06:45 Topic: Next VCWG Charter 15:07:03 q+ 15:07:05 ... Update on the next charter. The process we went through: created a draft charter, reviewed by the advisory committee (AC) 15:07:14 ... At the point of ready to announce call for participation 15:07:38 present+ dmitriz 15:07:44 ... Then possibiltiy of DID WG also being a full WG. Recognition that participation of community members may be spread thin between two full-time WGs. So possibility of revising charter. Up in the air at this point. 15:07:47 present+ dlongley 15:08:04 ack ivan 15:08:06 ... We don't know for sure what the charter will be. There is agreement we want to have a VCWG, but the scope is unfortunately not clear at this point. 15:08:18 ivan: I think you jumped some hooplas, and we have to get the minutes right. 15:08:25 ... We did not get ready by the AC, a long way not. 15:08:30 brent: At the point of asking for it? 15:08:40 ivan: Not. At stage of notifying of working on new charter. 15:08:47 ... Happy to have discussion with the AC - an open discussion. 15:08:57 ... When the waves are quieted at that one, can go do the review. 15:09:05 ... We were at the point of announcing to the AC that we were working on this charter. 15:09:14 ... I had most of things lined up for that, and then we got to this point. 15:09:24 ... So we are way earlier in this process than what you described. 15:09:47 Topic: Review PRs 15:09:50 q+ 15:09:51 brent: Apologies to the group. It was "Hey AC, we want to talk about this charter" - not "we have this charter" 15:09:56 https://github.com/w3c/vc-data-model/pulls 15:10:01 ack manu 15:10:12 q+ to discuss PRs 15:10:29 brent: We have some PRs to review. Before we jump into PRs... David, I believe what you were looking for is a brief kind of review of GitHub guidance for raising and submitting PRs, and responding to comments in them. 15:10:40 present+ MKupjetz 15:11:16 DavidC: Yes. When working on the original version, I used GitHub Desktop. In this version, some got accepted on the browser, and that threw my desktop somehow, got out of sync, hopelessly tangled (Credentials vs. Verifiable Credentials) - which you did fix, thanks; I don't want to get in that mess again. 15:11:32 ... Ted, I think you said you can do everything in the browser? If that is the case, I would like to do that. 15:11:43 brent: Since we did the first spec, GitHub functionality has expanded quite a bit for what you can do in the browser. 15:11:53 ... I still prefer the desktop process, since that's what I'm most familiar with. 15:12:13 ... One thing you may have run into is that when you accept suggestions from folks, it can make the version you are working on online out of sync with your desktop version. 15:12:19 DavidC: Exactly, right. 15:12:26 brent: So you need to pull changes to your desktop. 15:12:36 ... But the real process is to say "this isn't working for me, please help" 15:12:41 ... And there are folks more than happy to help untangle things. 15:12:57 ... Because regardless of the amount of experience you have, you will inevitably end up GitHub-tangled if you do it enough. 15:13:00 Git itself is a maze of twisty windy passages, all different. 15:13:07 DavidC: I will try using the browser, given it's got new functionality. 15:13:11 ... I've also used GitLab. 15:13:35 ... After we finished the recommendation in 2019, for our development work we used GitLab instead, and I found that browser worked very well - so I didn't bother using desktop. 15:14:05 brent: ... The web capabilities are better... 15:14:10 DavidC: ... Thank you 15:14:46 https://github.com/w3c/vc-data-model/pulls?q=is%3Aopen+is%3Apr+-label%3Adefer-v2 15:15:05 brent: Starting at the top: 819 15:15:13 subtopic: @pr#819 15:15:20 subtopic: @pr819 15:15:57 q? 15:16:05 ... This is a PR that uses a URI id for credentialStatus and refresh service. It has a couple approvals already. 15:16:33 ... This was in response to an issue that said... some say URI, some say URL. This takes the two instances that say must be URL, and change to say must be a URI. 15:16:50 kdenhartog has joined #vcwg 15:16:53 ack manu 15:16:53 manu, you wanted to discuss PRs 15:16:54 ... Last time, we discussed, this might not actually be a breaking change? 15:16:59 present+ 15:17:11 manu: This is a normative breaking change. It doesn't matter if it's a subset: we are changing the normative... what's allowed. 15:17:28 ... Even if nobody cares, it's technically a 1.2, thing, and it's labeled as such. 15:17:37 brent: Question for group: do we agree that this is a bug in the specification? 15:17:46 normative, but should not be breaking, because it relaxes requirements. I think it does class as a typo bug. 15:17:49 ... If it's not, it needs to be deferred to v2. 15:18:06 manu: I didn't get a change to review... I recall we limited it on purpose - but don't remember if it was these two things specifically. 15:18:19 ... I want to be careful about this change because I believe we said you want to be actually able to go out and discover this information. 15:18:32 ... I'd like a little more time to review it, to make sure we are not undoing something we wanted to do. 15:18:43 @manu +1 15:18:53 q+ 15:18:55 brent: That is the primary question. Is this addressing errata. Is it substantive... because we can only make substantive changes in response to errata. 15:19:00 I also remember that it was a URL so that it could be fetched 15:19:01 ... If we can't answer that, it will be deferred. 15:19:23 q+ 15:19:25 kdenhartog: The only time I'm aware of this being a concern is with credentialStatus and Revocation Status 2020. There is a normative statement that references an id and says it needs to be linkable. 15:19:27 acl kdenhartog 15:19:31 ack kdenhartog 15:19:33 ack manu 15:19:37 ... They are utilizing the VC Data Model... that could create a conflict... suggest taking a look at it. 15:19:54 q+ 15:19:56 manu: Now... my memory is being jogged... we absolutely meant URL. So I believe probably the fix is wrong and we shouldn't merge this. 15:20:02 ack TallTed 15:20:05 ... But I would like more time to dive in and consider it. 15:20:24 TallTed: I'm fine with having the discussion in the GitHub pages... but having a URL does not guarantee it is deferencable any more than URI... 15:20:41 ... URL abstracts by location... just a construct that makes it easier for humans to look at it... It's a difference without a difference. 15:20:54 ... Like I said, we can have the argument in the GitHub pages... but it will just go on forever if we need to. 15:21:02 there would be no problem with revocation status type imposing additional constraints on top of the vc data model spec 15:21:07 brent: Reminder, the conversation minuted here will automatically go into the PR. I agree that conversation should continue there. 15:21:14 (in response to kyle) 15:21:16 I agree with TallTed -- we probably need to say "you have to be able to get information from the URI" or something to that effect 15:21:17 brent: We'll move to the next Pull Request. 15:21:19 subtopic: @pr 818 15:21:21 https://github.com/w3c/vc-data-model/pull/818 15:21:42 ... PR 818. Update normative statements in the ZKP section. A little more extensive of a PR. 15:21:55 ... Kyle, since you're here, can you walk us through the changes 15:22:15 kdenhartog: Just trying to update things as best as possible. Particularly in the normative statements, but also to go around addressing smaller fixes to make it more readable 15:22:34 ... to make the ZKP section be able to fit CL signatures, particularly with Anon Creds 15:22:42 ... but also to allow the BBS+ suite. 15:23:08 ... The main things are the list, basically removing the requirement to use a credentialSchema - and also tweaking the possibility to generate a proof... 15:23:33 ... It says it must contain a proof property... obvious. The additional constraint is so the holder can derive credentials to reveal only what they want to reveal. 15:23:51 ... So I was trying to convey the ZKP must have some ... property 15:24:11 ... The ZKP layer, mainly around the guarantees of the credentialSchema, making sure not to change guarantees around leaking additional information. 15:24:19 ... Also in the proof, the ability to link things to the credentialSchema. 15:24:30 ... Sorry, that was tough... 15:24:44 brent: Thank you, we know it is late/early where you are 15:25:01 brent: Ted has raised concern about some language around holder binding. I think these are valid concerns and we should have conversations around it. 15:25:11 ... I don't know if this place is the right place to have those conversations. 15:25:11 i don't think this PR uses that language (would have to double check) 15:25:20 ... The comments were around things in the spec that this PR isn't changing. 15:25:30 q+ 15:25:31 ... I wouldn't want to hold up this PR, but would like to work on addressing this concern. 15:25:35 ... What does the group think? 15:25:37 ack TallTed 15:26:03 q+ 15:26:15 TallTed: I'm fine with spinning it out into a different issue - I just raised the comment there because that's when I noticed it - don't know how it slipped by in past readings. 15:26:22 ack kdenhartog 15:26:25 brent: I think this is an important conversation to have, ties in with other issues. 15:27:10 kdenhartog: To add to that, I think this is an indication that ... broader changes, decoupling the subject/holder binding issue... better to address separately. 15:27:26 brent: Ted, if you would open a new issue... 15:27:32 TallTed: I'll spin one up now. 15:27:46 subtopic: @pr 817 15:27:54 https://github.com/w3c/vc-data-model/pull/817 15:27:56 brent: 817. Removing proofs from examples. 15:28:07 ... I think we could have quite a conversation around this today - happy to spend time doing that. 15:28:17 q+ 15:28:18 ... This PR does what it says the title is - removes the proof property from examples. 15:28:22 ack manu 15:28:23 ... What do folks think? 15:28:52 manu: I would like David to intro - but I have to go in two minutes. Real quick... I think it's problematic to remove the proof property from all examples. 15:29:06 ... I think it's okay to talk about Creds vs VCs - that has been merged... 15:29:21 ... I think we should have example of JWT-based proof, vs. no proof, vs. linked data integrity proof. 15:29:30 ... But this PR removes proof from all examples... strong -1 to doing that. 15:29:40 DavidC: I've put my rationale in the PR. 15:29:49 ... Basically, when we started, we all thought every credential would have a proof property. 15:29:57 We thought there would be VC w/o proof property 15:29:58 ... I don't think anyone thought we wouldn't have a proof property. 15:30:08 ... We didn't know what it would like, so we put `"proof": ...` 15:30:21 ... Then Oliver added JWT... we had the discussion what does the proof look like for JWT... 15:30:31 ... Manu argued the proof property should be removed, so it was... 15:30:43 That's definitely not what the set of arguments were :( 15:30:44 ... That makes all the examples invalid if you are talking about verifiable credentials in general. 15:30:54 ... I think we should be consistent... 15:31:01 ... Either use JWT, or remove proof... 15:31:35 brent: To rephrase what Manu was saying, I don't think he was disagreeing with you in principle... just may need more deliberation rather than wholesale removal of all of them. 15:31:37 Yes, what Brent said. 15:31:46 -1 for removing proof from majority of examples :( 15:31:47 DavidC: I can go along with that if the majority... 15:31:53 q+ 15:32:02 ack kdenhartog 15:32:07 ... but just to randomly scatter properties into the examples without a logical reason - I'd like to know what the reason would be 15:32:11 maybe we want a comment above the proof: "..." property that says "// or 'proof' is externalized via JWT" 15:32:25 kdenhartog: What i saw come from Michael Herman that I thought was reasonable was the ability to do multiple credentials - with a tab(?) format 15:32:46 ... Would it make sense to use [different formats]? 15:32:59 DavidC: I think that would be great, but a lot of work... And the ZKP people may ask for a tab. 15:33:05 q+ 15:33:05 ... And the mobile driving license people may ask for one... 15:33:10 ... There is just that issue to consider. 15:33:17 ack kdenhartog 15:33:28 +1 kyle 15:33:38 kdenhartog: Yeah, in my opinion, ZKPs would be reasonable since we have sections to describe it. mDLs may be out of scope, as no one has been able to align the two data models to show compliance at this point. 15:33:42 +1 to tabs being a better solution 15:33:43 brent: Conversation can continue in the PR. 15:34:02 I'm happy to help around work for this stuff as well to get the tabs in 15:34:17 subtopic: @pr 816 15:34:19 ... There is a possibility that as the PR is reviewed in the next few weeks we can come to agreement on it - or in beginning of October... pretty firm cut-off point for normative/substantive changes in the revision. 15:34:22 ... Next: PR 816 15:34:26 https://github.com/w3c/vc-data-model/pull/816 15:34:54 DavidC: I raised this because it was on a different list - TallTed asked me to point to it here. 15:35:08 ... Some people are creating schemas that cover the credential subject and not the whole credential. 15:35:16 ... I thought this could be because the text is not clear. 15:35:29 ... First thing I found is that there is no statement that the credentialSchema must be present. 15:35:36 ... But that would be a breaking change. So made it a "CAN". 15:35:46 ... I think the text is clear that the schema property is for the entire credential. 15:35:56 ... But there are now two other issues which I've put there: what about verifiable presentations? 15:36:08 ... There could be different flavors of VPs... If the group agrees, we could put schema for VPs. 15:36:31 ... The second issue: Should we put a note in, to specifically say that the schema is not intended to apply just to the subject. 15:36:47 +1 I'm good with adding those to this PR 15:36:51 brent: I am personally fine with those additional pieces of text being added to this PR, just because it is part of the same conversation we've been having. 15:37:06 ... I'm not opposed to the addition of normative language if it's needed to address errata. 15:37:35 ... I agree with Manu that in this case it would be difficult to say how this would be testable. Making a normative statement may not give us the assurances we are hoping for. And as you said, changing it to a "CAN" is fine. 15:38:05 ... So the normative change would be to add a schema property for use in the VP. I think that is arguably errata and could be incorporated in the revisions we make, as long as it goes in this review period. 15:38:12 ... Any questions, comments, before moving on to the next PR? 15:38:22 manu: o/ 15:38:26 subtopic: @pr 814 15:38:38 https://github.com/w3c/vc-data-model/pull/814 15:38:41 brent: 814 is intended audience purpose and goals and non-goals. 15:39:05 ... This is in response to a couple of issues. This PR adds to the introduction some deliberate language around who the intended audience for the recommendation is or should be, or who we were writing it to. 15:39:22 ... Long conversation back and for there; as well as a purpose statement, for the goals of the specification. 15:39:37 ... I think a number of these additions could be beneficial for the specification. Some of them are not clear to me how necessary they are. 15:39:42 ... I don't see Michael Herman here... 15:39:43 q+ 15:39:49 ack dlongley 15:39:50 ... I know he and Dave have been having the bulk of the conversation... 15:39:56 ... Dave, would you talk about this PR? 15:40:10 dlongley: Sure. My feedback is largely around do we agree on the purpose and intended audience. 15:40:18 ... I thought was added here might be a little broad. 15:40:34 ... I've given that feedback to Michael... I think he said he would address those concerns. 15:40:40 ... I think more people should look at this PR 15:40:48 ... to make sure it matches our intended audience and purpose. 15:40:55 ... I think we should get more approvals on it to accept it. 15:40:59 brent: +1, please review. 15:41:10 ... This one in particular, is arguably editorial, but makes a lot of statements. 15:41:35 ... If we don't agree these are statements that we as a group want to make... those are questions we need to address. 15:41:40 subtopic: @pr 780 15:41:48 +1 more reviews/input/confirmation == more better 15:41:48 https://github.com/w3c/vc-data-model/pull/780 15:41:54 brent: One more... in case anyone has had this brilliant realization: what should the subtitle of our data model be? 15:42:10 ... There has been quite a conversation, refining it... 15:42:17 ... The summary at the end was... let's just keep looking. 15:42:28 ... If no one has anything more to suggest, we'll move on to issues. 15:42:34 Topic: Issue Triage 15:42:37 ... Not seeing anyone jump on the queue... 15:42:43 q+ 15:42:48 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+-label%3A%22substantive+change+v1.2%22+sort%3Aupdated-asc+-label%3Av1.1+-label%3Adefer-v2 15:42:52 ack kdenhartog 15:43:07 kdenhartog: I wanted to see if we could prioritize the substantive changes, since that's what I had prioritized. 15:43:29 brent: Yes - I am fine doing that, because any issues that we triage as 1.2 - it's pretty much too late to actually address at this point. 15:43:39 ... If no one else is opposed, we can do right to the 1.2 issues that have already been triaged. 15:43:43 ... How do folks feel about that? 15:43:53 ... Okay, then let's do that. Good point, Kyle. 15:43:57 Topic: Review v1.2 Issues 15:44:05 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+label%3A%22substantive+change+v1.2%22+sort%3Aupdated-asc 15:44:14 ... This is all of the 1.2 issues ^ 15:44:33 kdenhartog: First one I'm seeing is issue 726... 15:44:34 https://github.com/w3c/vc-data-model/issues/726 15:44:41 subtopic: @issue 726 15:44:47 kdenhartog: This one we were able to get covered - there is a PR for it. 15:44:52 ... The discussion is ongoing in #818. 15:45:04 bumblefudge has joined #vcwg 15:45:05 ... I believe we should be able to get that through after the issue that TallTed was able to open for us. 15:45:09 present+ 15:45:12 ... I'll go ahead and triage... 15:45:29 brent: Do we feel that the PRs that are open address these issues specifically? 15:45:30 +1 that ZKP PR would address this 15:45:35 ... For this one, I believe yes 15:45:41 ... but look forward to others' opinions. 15:45:50 kdenhartog: Looks like yes, in IRC chat... I'll assume it's good to go. 15:45:50 subtopic: @issue 782 15:45:53 https://github.com/w3c/vc-data-model/issues/782 15:45:56 ... Next we have 782 15:46:35 kdenhartog: Orie found some good details where xsd:dateTime is slightly different from what's defined within RFC 3339, then goes to highlight this. 15:46:56 ... There's currently no PR open. It was my intention to open a PR for this, but not sure how to do it. Manu has dropped some suggestions... 15:47:17 ... We're waiting for someone from itn(?) since they opened it. 15:47:23 i18n 15:47:37 s/itn(?n)/i18n/* 15:47:40 brent: My recommendation is if we get in a PR today, we can announce it is under review at the CCG today... then we can refine that PR according to discoveries we make during the two-week PR, and will have addressed the process requirements 15:47:47 ... so that this change can end up as part of our revision. 15:47:50 kdenhartog: That makes sense. 15:47:57 ... I'm uncertain if I'll get to it today - but in the next day or two. 15:48:15 brent: As long as we get a PR whose review period would end by end of September, we should be okay. So today or tomorrow. 15:48:22 kdenhartog: Next: 818 15:48:44 brent: The link I gave combined issues and PRs... apologies... one more issue, and it's not 888 15:48:50 brent: 748 is the one 15:48:51 subtopic: @issue 748 15:48:54 https://github.com/w3c/vc-data-model/issues/748 15:48:56 kdenhartog: Thank you for that 15:49:05 scribe+ 15:49:31 cel: This issue was about a variation between URLs and URIs and there's a PR open to address it 15:49:55 brent: We discussed earlier that a determination needs to be made around if this is errata or now 15:50:30 ... there's an argument to be made that it's not and I'm happy to here arguments on if it is errata 15:50:50 q+ 15:50:50 .. right now it's considered an errata and we need to finalize that decision as a WG 15:51:02 ack DavidC 15:51:25 DavidC: I don't think we have to resolve this today - can give Manu more time. 15:51:42 kdenhartog: I agree, and expect he may be able to cover it, although he may be on vacation. 15:51:49 I'm good to triage 15:52:01 Topic: Triage Issues 15:52:02 brent: Anything else? Or can do some issue triage for 1.1 issues to address 15:52:08 https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+-label%3A%22substantive+change+v1.2%22+sort%3Aupdated-asc+-label%3Av1.1+-label%3Adefer-v2 15:52:22 brent: This should be all the issues that do not have a label ^ 15:52:35 https://github.com/w3c/vc-data-model/issues/797 15:52:36 kdenhartog: First one I'm seeing is #797 15:52:44 subtopic: @issue 797 15:53:07 q+ 15:53:09 ... Short summary: this is basically something that's led to a separate CCG work item - hence why I've labeled it related content... really just a filtering mechanism so I don't have to keep having it pop up in front of me as something untriaged... 15:53:23 q+ 15:53:26 ... Intent is to have closed... given it is a CCG work item I don't think we need to formally track it. 15:53:33 ack brent 15:53:54 ack brent 15:53:55 brent: Because he has formulated it as a "principled objection", I do need to, as a chair, reach out to him... There is a little more process we have to go through before saying we are resolving this. 15:54:05 ... I will reach out to Michael Herman... 15:54:10 ack DavidC 15:54:36 DavidC: I didn't think that it was a CCG work item... I thought we have a meeting next week that it is a proposal for a new work item - and won't know if it will be accepted until next week. 15:54:46 brent: I agree. Hopefully another work item owner volunteers. 15:54:55 DavidC: I think we've had another volunteer already. 15:54:58 brent: Excellent. 15:55:02 kdenhartog: I believe that covers it for now. 15:55:06 https://github.com/w3c/vc-data-model/issues/813 15:55:08 subtopic: @issue 813 15:55:33 kdenhartog: #818. This is actually a non-triaged one - what we want to do in terms of handling the PR that is already opened. 15:55:43 ... We've been able to discuss this now... about making sure that people are reviewing this. 15:55:53 ... I think the general assessment here is that if there is something, it would be a v1.1. 15:56:02 ... My personal take is that these are kind of obvious things that don't need to be statement. 15:56:03 +1 15:56:10 ... So I kindof see this as a non-issue if it is anything. 15:56:21 brent: Agree... does anyone disagree that this is a v1.1? 15:56:22 it if ends up being addressed it's 1.1, IMO 15:56:30 ... if it ends up being addressed, that it is non-normative and non-substantive? 15:56:42 ... Okay, I'll go ahead and add the v1.1 label to it, and we can move on. 15:56:45 https://github.com/w3c/vc-data-model/issues/815 15:56:49 kdenhartog: Sweet, thank you. Netx one is #815. 15:56:52 subtopic: @issue 815 15:57:11 ... This one is a thing that has spawned out of one of the PRs that he raised, I believe. This is about being able to add the tabs in there... 15:57:31 ... I did do some research on how this is possible... Looks like there is some good stuff already written out in the JSON-LD spec that makes this possible... 15:57:42 ... I'll look at it, but unlikely in the next day or two... 15:57:53 ... If we're fine with triaging this as 1.1, I think that gives us a little more time. Is that correct, Brent? 15:58:11 brent: Yes, we have a couple more days to produce a static version with all the substantive changes that require a 60-day review. 15:58:32 ... If at the end of the review, we have unsubstantive changes, I believe it is okay to add those... is that right, Ivan? 15:58:50 ivan: I'm not going to correct you. 15:58:53 well, you're not wrong 15:59:08 brent: I'll go ahead and label this 1.1. 15:59:15 https://github.com/w3c/vc-data-model/issues/820 15:59:17 kdenhartog: Sweet. Looks like we have one minute left... 15:59:24 ... last one is #820 - a new one that just popped up 15:59:29 ... I haven't had a chance to read it... 15:59:39 ... I don't even know how to address this... 15:59:47 brent: On first reading it doesn't seem like they are requesting changes 15:59:47 subtopic: @issue 820 15:59:54 ... to the specification, just asking for clarity 15:59:58 ... I believe we can label it as a Q 16:00:15 kdenhartog: I believe this may be similar to David Chadwick's PR... I'll take a look 16:00:21 brent: In the meantime, I've put the label. 16:00:31 ... Thank you everyone for your hard work, especially these last few weeks. 16:01:03 ... I look forward to seeing I think one more PR Kyle from you, then we'll make a static version, vote on as a group that we want to submit it as a revised recommendation, and that begins the 60 day review period. 16:01:14 ... So we are still on track. Thank you everyon. Thanks Charles for scribing. 16:01:31 zakim, end meeting 16:01:31 As of this point the attendees have been ivan, by_caballero, cel, brent, manu, TallTed, wayne, DavidC, rgrant, dlongley, dmitriz, MKupjetz, kdenhartog, bumblefudge 16:01:31 s/everyon/everyone/ 16:01:34 RRSAgent, please draft minutes 16:01:34 I have made the request to generate https://www.w3.org/2021/09/15-vcwg-minutes.html Zakim 16:01:37 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:01:40 Zakim has left #VCWG 16:02:31 rrsagent, bye 16:02:31 I see no action items