15:14:43 RRSAgent has joined #did 15:14:43 logging to https://www.w3.org/2021/11/09-did-irc 15:14:44 inviting RRSAgent 15:14:46 RRSAgent, make logs Public 15:14:47 please title this meeting ("meeting: ..."), ivan 15:15:09 Meeting: DID WG Telco 15:15:09 Chair: burn 15:15:09 Date: 2021-11-09 15:15:09 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Nov/0000.html 15:15:09 ivan has changed the topic to: Meeting Agenda 2021-10-19: https://lists.w3.org/Archives/Public/public-did-wg/2021Nov/0000.html 15:15:09 ivan, sorry, I did not recognize any agenda in https://lists.w3.org/Archives/Public/public-did-wg/2021Nov/0000.html 15:51:07 burn has joined #did 15:52:14 burn has changed the topic to: Meeting Agenda 2021-11-09: https://lists.w3.org/Archives/Public/public-did-wg/2021Nov/0000.html 15:52:30 rrsagent, draft minutes 15:52:30 I have made the request to generate https://www.w3.org/2021/11/09-did-minutes.html burn 15:52:41 rrsagent, make logs public 15:52:51 present+ 15:57:17 rgrant has joined #did 15:57:38 justin_r has joined #did 15:57:58 present+ 15:58:41 present+ justin_r 15:59:48 present+ shigeya, brent 16:00:39 present+ dlongley 16:00:44 scribe+ dlongley 16:01:09 present+ manu 16:01:16 present+ TallTed 16:01:29 mprorock has joined #did 16:01:41 drummond has joined #did 16:01:52 present+ 16:01:54 Topic: Agenda Review, Introductions 16:02:14 present+ 16:02:15 present+ rgrant 16:02:15 burn: So the agenda for today is actually much simpler than we've had in the past. We really want to just address this topic of DID method value judgment. 16:02:24 present+ mprorock 16:02:37 burn: It's something that's holding us up on moving forward on DID registries, that's the main topic, there will be other quick updates before that. Any changes to the agenda? 16:03:10 Topic: v 16:03:14 Topic: Special Topic Call 16:03:16 burn: Let's get right into the first update. This is on the special topic call. 16:03:58 burn: We do have time reserved later today at our special topic call time which is 6PM ET. If we need it. The intent is to spend our time on the DID registries value judgment topic. If we get into some other conversations and we don't have time on that then we'll have the special topic call, otherwise we won't. 16:04:16 burn: If the group would still like to that have that call later we can for some reason, it's there as a backup. 16:04:31 s/Topic: v/ 16:04:37 Topic: Media subtype suffixes at IETF 112 16:04:55 manu: As most of you know, we tried to register `did+ld+json` through IANA. 16:05:14 manu: They were like "we don't know what those two plus signs mean, how should we interpret those". The DID WG then created a draft for how you should interpret multiple suffixes. 16:05:19 Here's the draft we prepared: https://datatracker.ietf.org/doc/html/draft-w3cdidwg-media-types-with-multiple-suffixes-01 16:05:21 manu: Here's the draft (in IRC). 16:05:45 manu: Amy and I worked on that and she put it together. They said "well, that's great but we don't have a WG to process it". So they created a WG to process it and some other things. 16:05:55 manu: That WG met today and took up the question on accepting the draft. 16:05:57 Here's the result of the poll: https://mailarchive.ietf.org/arch/msg/media-types/2DEvUeOYeqMrEKIdaO4A-djT_9Y/ 16:06:21 manu: The result of the poll was that they like the draft at a high level, there's some details to work out but 10 in favor, zero opposed. 16:06:50 manu: If there are no objections on the mailing list they will ask to make that a WG draft. I volunteers to be the editor, I'll check with Amy to see if she has time, I don't think we does. 16:07:12 manu: So there are now multiple ways to have suffixes. Some people wanted to be very specific about what suffixes meant and so on. 16:07:25 manu: If you want to go support on the media types mailing list that link will let you do that. 16:07:37 burn: Cool, hallelujah! This is a long time in the making. 16:07:39 q+ 16:08:01 ack ivan 16:08:04 burn: It will be interesting to see if there's additional guidance on details. 16:08:07 q+ 16:08:15 ack manu 16:08:19 ivan: Is there guidance on a new DID spec / changes there? 16:08:46 manu: I think we already put that in DID core. We already said "This is the media type and it has two plus signs and we'll register it whenever it becomes a thing at IANA". So, in theory, we shouldn't have to do anything with the DID core spec. 16:08:50 We do say we'll fix this in a future version: https://w3c.github.io/did-core/#application-did-ld-json 16:09:32 ivan: You are right, I see that. That means that we can do the formal ... this is now ... this means that the current `application/did+json` and `application/did+ld+json` are not normative? 16:09:43 manu: `application/did+json` is normative, `application/did+ld+json` is not. 16:09:47 ivan: That's not clear in the spec. 16:10:07 manu: We do say it's non-normative, but it's a bit weird because the spec says we'll be removing those sections at some point because they just have to do with IANA registration reminders. 16:10:13 ivan: We are in good shape to finalize all that. 16:10:18 burn: Anything else on this topic? 16:10:24 burn: Thank you. 16:10:24 Topic: DID Registry PR review as background 16:10:45 present+ by_caballero 16:10:46 q+ to provide some background on what's ready in PRs. 16:10:55 burn: DID registry PR review as background. When Brent and I were discussing this, before we get into the key topic DID method value judgments, we thought it would be good to review the background on relevant PRs. 16:11:03 burn: I'd like someone to take us through that -- Orie ideally. 16:11:05 manu: I can. 16:11:17 burn: I don't want to get into the discussion yet, just concrete examples for alternatives for understanding. 16:11:25 manu: Understood, there are no alternatives now. 16:11:37 We are aligned on the way forward. 16:12:00 manu: I think Orie and I are totally aligned. There's no controversy anymore, we figured out a way to structure everything so that everything the group said was important to them last week and the way Orie and I wanted to process these things ... we should be almost completely aligned and where we aren't we can fix those up quickly. 16:12:10 manu: Maybe we can just go through those and then have a discussion. 16:12:14 burn: Alright, cool. 16:12:39 manu: There can be controversy at the end when we discuss value judgments but the current set of PRs don't get into that at all, they are just about what the group agreed to. 16:12:43 https://github.com/w3c/did-spec-registries/pull/353 16:12:48 manu: So, the first one that we're talking about is PR #353. 16:13:23 manu: All this PR does is that it takes the existing table of DID methods and converts it into JSON. It doesn't add new fields, it doesn't add pointers to rubric or anything. It's just the table we have right now converted to JSON. Shouldn't be controversial. 16:13:29 q? 16:13:31 ack manu 16:13:31 manu, you wanted to provide some background on what's ready in PRs. 16:13:34 manu: In the future, we can have other fields with links to rubric, examples, things like that -- but that's not in this PR> 16:13:39 s/PR>/PR./ 16:13:43 manu: Any questions? 16:13:51 No, that's clear. 16:13:56 https://github.com/w3c/did-spec-registries/pull/357 16:14:47 manu: Seeing no one on the queue, the next PR is #357. This PR builds on the last PR. It takes the JSON files and it just renders them with the same information that exists today in the thing that we have published. No new fields, doesn't contemplate anything new, no value judgments, just a list of DID methods and contact info, etc. the things we already have in the table. Shouldn't be controversial. It uses a respec extension to render the table 16:14:47 instead of being static. 16:15:00 Very clear. 16:15:00 manu: There's an image of what the new rendering looks like. 16:15:13 q+ 16:15:13 s/instead of being static./manu: instead of being static./ 16:15:33 ack rgrant 16:15:38 burn: I have a feeling we may end up sliding into the value judgment discussion, so if there's anything you want to hit before that please talk about those things. 16:15:51 rgrant: What were the options for changing respec in this way and can we summarize the strategy taken? 16:16:41 manu: Two options: One was to depend on a command line tool to generate the HTML and commit to github, Orie implemented that last week. Option two was to use respec and pull the information from the JSON and render in full time. The end result is the exact same. The suggestion to do it through respec is to avoid junk getting generated as a part of change history. 16:16:43 q+ 16:17:00 manu: It also allows people to hack on display and rendering without having to install node.js tooling and run command line tools. 16:17:39 rgrant: I agree that's the better way to go. I'm having trouble understanding if I'm running local respec, I see common.js changing -- these are local to the repository presumably, so anytime I have this repo, respec will automatically do the right thing or how do I pull those in and make sure I'm using the right respec stuff? 16:18:08 manu: Let's talk about that offline. Basically, you shouldn't have to deal with any of the node.js stuff. It should be as easy as load the file in your browser and modify `common.js` -- if that doesn't work something is broken. 16:18:20 manu: If all you want to do is mess with the rendering that should be it. 16:18:30 rgrant: Right, it should work, it shouldn't change anyone's build process. 16:18:31 ack ivan 16:18:31 manu: That's right. 16:19:02 ivan: I have a project which is a bit similar to what you did, Manu. It's producing testing reports for another WG where we expect to have a large number of tests. Those are expressed in JSON and then we do whatever you do as well. 16:19:28 ivan: The experience I had when I was doing that was that it becomes a bit slow when you go to a page and you expect a result. It goes quite slow, I wonder if you have this problem. 16:19:38 q+ to note it takes ~250ms to render the entire table. 16:19:41 agropper has joined #did 16:19:52 ivan: What I decided to do in the end was sort of the Orie way, I have a process that generates the necessary things and I use github actions to do this automatically and it even runs the respec stuff. So the user just sees the generated HTML. 16:19:59 present+ 16:19:59 ivan: I wonder whether we can get through a timing issue like that. 16:20:13 manu: So that was considered, it takes ~250ms to render the entire table, so the mechanism we have right now is fast. 16:20:15 ivan: Ok, good. 16:20:23 manu: And it's not expected to slow down as we get 200-500 more entries, etc. 16:20:27 manu: It should be just as fast. 16:20:31 ivan: Ok. 16:20:52 https://github.com/w3c/did-spec-registries/pull/360 16:21:17 present+ pam 16:21:27 manu: Noting time, I'm going to keep going. The third one has to do with a registration template. We have to explain to people how to do it -- before it was hack the HTML and now it's edit a JSON file. The editors don't want to have to tell people that they forget a quote mark or whatever, so Orie implemented validation. 16:21:44 manu: He also creates a new PR template that requires people registering to do the checks themselves so we don't have to keep telling them these things. 16:22:13 manu: So before they even raise the PR they have to self-attest to those things. Once they submit the PR, Orie's tooling runs and does a schema validation and the PR can't be merged until the checks pass. 16:22:32 manu: So this has to do with making sure the editors don't have to do extra test. Actually, I messed that up, I just explained two different PRs. 16:22:44 manu: PR #360 are only the instructions to the individual. PR #361 has the tooling. 16:22:56 manu: PR #360 -- any concerns over having a registration template to fill out? 16:22:59 q+ 16:23:03 q- 16:23:13 ack drummond 16:23:22 drummond: It makes total sense. We don't really have any option if we're going to this form of doing it, we need clear instructions for registration. 16:23:31 drummond: Do we run validation against what they submit to make sure it's well formed? 16:23:40 q+ 16:23:45 q+ 16:23:46 manu: Yes, with a tiny caveat about something you care about -- we'll get to that. 16:23:50 manu: I suggest people look at the template. 16:24:03 manu: Ideally, it would be best if we merged all four of these PRs together, we don't have to, but that's the desire. 16:24:04 ack rgrant 16:24:35 rgrant: Thanks, I noticed that TallTed suggested that there should be a maximum time until registration, should we talk about that or should we wait for comments on that? 16:24:36 ack ivan 16:24:38 q+ 16:24:44 Looks good, and I will update my PR (#336) 16:24:53 q+ 16:25:04 manu: This is a volunteer driven thing -- and having a maximum time is ... I don't want to put the editors under that and we will do our best. 16:25:09 ack manu 16:25:09 ack manu 16:25:21 pam has joined #did 16:25:26 manu: Unless we get more people that will step up to agree to such a timeline I don't want to force the editors to do that. Most of them are in the same position with being very busy. 16:25:31 present+ 16:25:39 ivan: We are talking about the tables for the DID method registration, right? 16:25:53 ivan: Or are we also we talking about various method data and parameters, etc. 16:26:02 manu: Let's try and scope the discussion to the former. 16:26:09 ivan: Will the same approach be used for the others? 16:26:17 manu: It's a good question, we should have that as part of the discussion. 16:26:17 ack TallTed 16:26:47 q+ 16:26:47 TallTed: Max time might be a year. I'm not trying to pile anybody's desk higher than it already is. We are saying it's not going to be less than 7 days and saying a year is enough slack time for anybody. 16:26:50 ack manu 16:27:05 manu: I think saying a year sends the wrong message. I think 30 days is fine. 16:27:12 I agree that a year is too long. 30 days feels right. 16:27:17 TallTed: Not saying anything seems like it takes forever. 16:27:29 manu: I don't think anything longer than 30 days. 16:27:34 +1 30 days 16:27:35 TallTed: 2 months is fine, not excessive but reasonable. 16:27:43 q? 16:27:48 manu: Anything else before we go to the last PR? 16:27:56 https://github.com/w3c/did-spec-registries/pull/361 16:28:36 manu: So this is the schema checking whenever someone is registering. This just makes sure the registration data is well formed. We also have a mechanism that rebuilds the list of all DID methods in JSON format. This is going back to Ryan's previous question. 16:28:40 Good! 16:29:09 manu: You don't have to run that tooling if you don't want to. We're going to run that as part of the github action, no one needs to run that to do development for rendering the table, etc. It's not checked into github, it's just part of the build process. 16:29:23 q+ 16:29:25 manu: That's only kicked off if the validation checks pass. This makes the editors' job easier. 16:29:28 manu: That's all 4 of the PRs. 16:29:54 Tremendous progress. I'm in favor of merging all four. 16:29:55 manu: I believe we're aligned, at least Orie and I are -- that it's the right approach. We'd like to get these PRs in as soon as possible because we're having to run beside all the new registrations right now. 16:30:02 manu: We don't want to have to keep doing that. 16:30:19 manu: The intent is to merge these as soon as possible, so we typically wait 7 days and that means 5 more days until merge. 16:30:20 ack rgrant 16:30:32 +1 thanks to everyone for all the work 16:30:37 IMHO, merging those PRs is completely orthogonal to any question of value judgements. 16:31:01 q+ 16:31:07 ack manu 16:31:15 rgrant: PR #361 looks really good for the editors but I'm confused when github is saying continuous integration is saying "no" -- is there a way to add more documentation around what needs to be fixed so you can send it off to the editors? 16:31:52 manu: Yes, we can certainly do that, the problem is that there are multiple things that will start running. You can always click on "details" and it should tell you what failed. We can put that in a README and tell people to do that even though most people may not read that. 16:32:10 manu: More often than not, the editors have to tell people that their JSON file is not formatted well and they have to fix it, but +1 for documentation to help there. 16:32:25 q+ 16:32:30 ack ivan 16:32:31 manu: The real issue comes in when W3C tooling wasn't working and people got confused and they didn't know if it was them or not -- and we had to tell them it would pass, etc. 16:32:52 q+ 16:32:56 ivan: One very specific thing from W3C, these things are important, do you check as part of your tooling whether the various URLs that appear are live or do they 404? 16:33:07 ack manu 16:33:10 ivan: I see 404 links today. 16:33:50 manu: That's an excellent question, we should be doing that in time, we didn't want to implement it right now. We just wanted to implement what people agreed to, we should talk about that as part of the discussion, we should talk about automated tooling that checks this stuff -- there are some links that point at marketing now instead of a spec and that's a problem. 16:33:53 manu: We should discuss that. 16:34:14 burn: At this point you've presented the 4 PRs and if anyone has concerns or objections please reply on those PRs -- without objections they will be merged in 5 days. 16:34:16 manu: Yes. 16:34:19 +1 to that process. 16:34:22 burn: Anything else related to that today? 16:34:32 burn: There were a couple of topics you said, Manu. 16:34:40 manu: This is the further discussion -- whether we want value judgments and whatever else. 16:34:44 manu: We can move into that topic. 16:34:46 The value judgement discussion at last! ;-) 16:34:52 Topic: DID Method value judgements: yeah or nay 16:35:09 burn: Yes, let's do that. There's a little bit of background on this as a reminder to the group. What we mean by value judgments and alternative positions on this topic. 16:35:19 burn: Could you summarize, Manu? 16:36:00 manu: The registration process today has the editors doing to the link provided for the spec and saying whether it's "good enough". We typically look to see that they've defined the DID syntax, that they've written something vaguely understandable on the CRUD operations and a sizable security/privacy section. 16:36:29 q+ 16:36:34 manu: We want there to be at least 3 bullet points, some paragraphs there -- fundamentally we're making a value judgment. There's a question about whether we should be doing more, less, automating, removing these requirements, etc. 16:37:03 manu: Those are the kinds of value judgments we're making today. There is also a suggestion that we should put other fields they should provide such as a link to an implementation, a link to a test suite, or test output for the DID test suite. 16:37:46 manu: Do you have a further test suite of your own -- there are things that we can ask them -- that aren't value judgments and people can include it in their registration. There are two discussions there: 1. do we want to ask for more information? 2. do we want to make value judgments and if so, what is appropriate? 16:37:47 q+ to mention consistency and non-binary outcome 16:37:48 q+ to specifically require a value judgement of basic DID method specification conformance 16:38:04 ack 16:38:08 ack burn 16:38:08 burn, you wanted to mention consistency and non-binary outcome 16:38:09 manu: Today we some of those value judgments today and the editors don't want to have to do that, if we can automate it that would be great and some people don't want us to do it at all. 16:38:34 burn: There's a desire for consistency -- if we allow for value judgements how do we ensure that over time the editors can operate in a moderately consistent manner with those judgments. 16:38:53 +1 to automation. -1 to editor value judgements or requiring external certifications (although listing them is fine). 16:38:55 burn: The title for this topic was a yay/nay on value judgments, it's not necessarily binary. I'll open it up for discussion now. 16:38:56 ack drummond 16:38:56 drummond, you wanted to specifically require a value judgement of basic DID method specification conformance 16:39:40 drummond: I'm a broken record on this... I'm going to leave off the topic of any other value judgment other than what I've been calling the baseline in all my comments. Basically the same level of editorial review -- basic DID method spec conformance. Does it meet the requirements of section 8. 16:40:11 drummond: It's not a really high or arbitrary bar. As maintainers should be able to make this judgment. Orie has said all maintainers must sign off, I don't think that should be required, I'd be happy with two. 16:40:14 q+ to provide what I think Orie is saying he wants if we do that "value judgement thing", then 3 editors will be more consistent than 1... and to say section 8 is a bit onerous. 16:40:34 q? 16:40:47 ack manu 16:40:47 manu, you wanted to provide what I think Orie is saying he wants if we do that "value judgement thing", then 3 editors will be more consistent than 1... and to say section 8 is a 16:40:49 drummond: If we don't set a bar for a baseline of quality for what it means to get into it -- then we're not doing a service for those people using the registry. It is a namespace, even though we don't really like those, we do need to guide against bad entries for users. 16:40:51 ... bit onerous. 16:41:36 manu: I definitely hear that, Drummond. I will try to explain Orie's viewpoint -- I'm on the fence about it. I think he's saying that if we're going to keep making judgments, he thinks different editors might ahve different opinions, so he wants all three editors approving it. 16:41:45 manu: That way we're raising the bar on being consistent on the evaluation. 16:41:53 q? 16:41:54 q+ 16:41:58 Note: If we want to have link to did core test results specific to a method , I need to find a way to create permanent link (currently it's changing) 16:41:58 q+ to propose 2 editors, but only needing a 3rd if the 2 disagree 16:42:21 manu: I think I agree with him but I don't like the extra work on the editors. The people doing this are very busy and this is an expensive process. The counter argument is that hopefully we won't get another 100 methods over the next year. I think the suggestion here is more than 1 editor. 16:43:01 ack pam 16:43:05 manu: With section 8 there are a lot of MUST statements in there. I don't try and check every single one of those -- there are 20-30 of them, I definitely don't do that level of checking. We would do that for a totally conforming thing -- to say that this spec conforms to section 8 -- I'd like to stay away from that until we have a way to automate it. 16:43:11 pam: How do we see this running in 10 years? 16:43:11 q? 16:43:20 ack drummond 16:43:20 drummond, you wanted to propose 2 editors, but only needing a 3rd if the 2 disagree 16:43:25 q+ how does it work in 10 years? 16:43:29 q+ to how does it work in 10 years? 16:43:50 drummond: I'm happy to, Pam, we could run it in 10 years exactly the same way we are running it today. I believe in 10 years we'll have a low level of new registrations. We may have updates to specs. 16:44:21 q+ to dig into the 10-year situation 16:44:31 drummond: What I wanted to get back to was a simple proposal -- to set the baseline is to say that 2 editors need to agree. If the two disagree then we need a third to break the tie. That keeps the bar as low as we can. That may address Orie's issue that if two don't agree you need a third to break the tie. 16:45:19 drummond: Listening to Manu, to minimize the work on the editor's part -- this would be an independent process, it wouldn't directly affect the registry, but a form of self-attestation, in addition to the spec you must fill out the form and say whether and how you meet the conditions in section 8. That would make it way easier -- make the submitters have to say how they conform. 16:45:40 drummond: There have been very new innovative ways of doing a DID method and it really helps to know how you've met the requirements. 16:45:51 ack manu 16:45:51 manu, you wanted to how does it work in 10 years? 16:45:55 drummond: So give us the answers to the questions, it would make registration review much easier. 16:46:51 manu: To try and wonder about 10 years, I think I agree with Drummond that we can run it the same way in 10 years. I want to automate everything. Remember W3C has tooling that automates the publishing process and it used to be very manual. We can push a lot of this work onto the DID spec authors -- like you need to have anchors in your spec, you need two paragraphs here or there, that sort of thing. 16:47:23 ack pam 16:47:23 pam, you wanted to dig into the 10-year situation 16:47:30 manu: My hope is that, Pam, we automate all of this so it's easy to maintain. Any new analysis that we want people to provide has tooling that does an automated check to make sure that they are self-attesting and two we're doing a sanity check equivalent to what the editors are doing today. 16:48:13 +q 16:48:19 ack justin_r 16:48:19 q+ 16:48:26 pam: We're creating state -- in a spec that is otherwise stateless (not an attack, just a statement). Will we still have editors in 10 years? If the top five methods are there -- will they have to start voting on new methods? What if they stop responding? This presupposes a level of long term support that is concerning to me. If automation will address that, great. 16:48:59 q+ to suggest adding a process that takes effect when editors all retire 16:49:19 justin_r: I don't believe automation will address any of Pam's concern. I think an internet epic of 10 years -- the concerns are very valid. IANA struggled with this for years before coming up with its current system, where the people that physically edit the registries and make the changes -- those people are separate from the people who are deciding what should go in there. 16:49:41 q+ to say automation isn't to solve quality control, but rather to inform method editors and create source data for rubric reviewers 16:50:00 justin_r: Because what happens if you can't get a hold of all of the experts? I'm a designated expert on a number of IANA registries at this point in my career. There's at least one registry where the designated expert has passed away. That kind of change needs to be accounted for. 16:50:31 justin_r: I'm hearing lots of hope and optimism and that's good energy to take into this but there needs to be more realism for this for long term stability and maintenance. That's the whole point of registries -- it's long term availability. 16:50:44 ack drummond 16:50:47 justin_r: For 6 months we can just point at a web page. This is for long term availability and consistency and that's important. 16:51:32 q+ to note registry process exists now :) 16:51:34 drummond: I agree with Justin. All of this is predicated on having a set of folks that volunteer to continue as registry maintainers and the more we have the more the work is distributed. I expect a completely set of people in 10 years. If W3C is taking on registries I'm curious why we haven't heard more formal action on it. 16:51:54 drummond: We heard a details proposal two years ago at the TPAC meeting. We will need people to help maintain it if we can't completely automate it. 16:51:54 ack burn 16:51:54 burn, you wanted to suggest adding a process that takes effect when editors all retire 16:52:00 drummond: AI is amazing. 16:52:02 dmitriz has joined #did 16:52:21 burn: I think it would be quite valuable to address Pam and Justin's concern -- if we add a process if the number of editors drops below a certain number. 16:52:45 burn: It's reasonable to do that in any organization -- in another case we talked about what happens if you fall below a certain number where you can't get a majority, etc. 16:52:55 burn: At 10 minutes to the hour I wanted us to talk next steps and here we are. 16:52:57 q? 16:53:05 ack rgrant 16:53:05 rgrant, you wanted to say automation isn't to solve quality control, but rather to inform method editors and create source data for rubric reviewers 16:53:05 burn: Do we need to continue this at the special topic call time? 16:53:08 q+ to suggest we've made enough progress. 16:53:17 q+ to time check 16:53:36 q+ 16:53:49 rgrant: I wanted to say that we're reopening the question of quality control in the DID method world. This is supposed to be an open environment, the registry is not supposed to tell people what a good DID method is -- I'd like Justin and Drummond to keep that in mind when we talk about automation. 16:53:56 q+ to talk about the baseline of quality for the registry 16:54:01 rgrant: We're talking about a few fields filed out in JSON, we shouldn't be grading for quality. 16:54:37 rgrant: Maybe Manu has other ideas on what to automate -- like in a security section in spec that might need more work. I'd like people to keep in mind that we still have a Rubric and Rubric-evaluators can go click links and read more about DID methods there. 16:54:59 ack manu 16:54:59 manu, you wanted to note registry process exists now :) and to suggest we've made enough progress. 16:55:04 rgrant: We aren't trying to satisfy formal objectors that think some DID method has a lot of junk -- we want more decentralization and we want to be better at censoring judgments. 16:55:05 W3C Registry Process 2021: https://www.w3.org/2021/Process-20211102/#registries 16:55:23 manu: To answer Drummond quickly there's a new W3C registry process and we could take that route to maybe address some concerns. 16:55:42 s/better at censoring/better at preventing editors or anyone else from censoring/ 16:56:12 ack burn 16:56:12 burn, you wanted to time check 16:56:13 manu: I suggest we've made enough progress today. We can merge down after the 7 day period and nothing bad will happen for the next month or two -- the only reason to meet would be to talk about the other fields that we want to include in the registration, like pointer to the rubric, pointer to example DID doc, so forth. I suggest we just use next week's call for that. 16:56:15 burn: Thank you. 16:56:32 burn: I will go ahead and say no special topic call today, I agree that we've been able to use most of the call on this area. 16:56:39 Just to make this point, in case we run out of time, the "quality" I'm proposing is a basic test of *conformance of the submitted DID method specification* to our Section 8 requirements. That's it. Anything else about the "quality" of the DID method should be handled by Rubric-based evaluations. Which is why having a field for pointing to them would be so helpful. 16:56:42 ack ivan 16:56:45 burn: With that, keep in mind that we have a few minutes left, two people on the queue, be brief. 16:57:40 ivan: To connect some dots, W3C has a formal process now for registries -- I connect this to what Justin said which I like very much which is to separate the experts who decide and those who do the mechanical work. Because the registries become part of the W3C work will hopefully use a team that will still exist in 10 years, they can make the additions provided that the experts say what to do. 16:57:53 ivan: Just like the team can update RECs that are 10-15 years old provided that the experts say what has to be done. 16:58:08 ack drummond 16:58:08 drummond, you wanted to talk about the baseline of quality for the registry 16:58:08 ivan: Going with the model that Justin described with this registry from day 1 would probably be a good idea. 16:58:59 drummond: +1 to that, I didn't know that process had been put in place. I suggest we all take the action item to read through that and understand the wisdom of Ivan's suggestion. I typed already what I think is to Ryan's point -- you can say it's a value judgment to say if something conforms to the spec or not, maybe we can automate it -- do you have the things required in the spec. 16:59:07 drummond: I agree, we could ask for links into the exact section 16:59:09 drummond: Yes, you can put in mush and the machine can't tell if it's useful. 16:59:42 drummond: That's the only thing but that's why I think we should include a field that's a pointer to evals done for the rubric, that's where we should be pointing people and encouraging people to have those evals done and make it easy for DID methods to be eval'd. 16:59:56 drummond: Let's keep the namespace as clean as possible and keep junk out to the greatest extent possible. 17:00:06 burn: Thanks, Drummond. 17:00:10 Huge thanks to Dave for scribing. 17:00:13 rrsagent, draft meeting 17:00:13 I'm logging. I don't understand 'draft meeting', ivan. Try /msg RRSAgent help 17:00:28 rrsagent, draft minutes 17:00:28 I have made the request to generate https://www.w3.org/2021/11/09-did-minutes.html ivan 17:01:10 zakim, end meeting 17:01:10 As of this point the attendees have been burn, ivan, justin_r, shigeya, brent, dlongley, manu, TallTed, drummond, mprorock, rgrant, by_caballero, agropper, pam 17:01:13 RRSAgent, please draft minutes 17:01:13 I have made the request to generate https://www.w3.org/2021/11/09-did-minutes.html Zakim 17:01:15 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 17:01:20 Zakim has left #did 17:01:21 rrsagent, bye 17:01:21 I see no action items