14:50:48 RRSAgent has joined #did 14:50:48 logging to https://www.w3.org/2020/04/07-did-irc 14:50:50 RRSAgent, make logs Public 14:50:52 please title this meeting ("meeting: ..."), ivan 14:50:54 Meeting: DID Working Group Telco 14:50:54 Chair: brent 14:50:54 Date: 2020-04-07 14:50:54 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Apr/0001.html 14:50:54 ivan has changed the topic to: Meeting Agenda 2020-04-07: https://lists.w3.org/Archives/Public/public-did-wg/2020Apr/0001.html 14:54:35 justin_r has joined #did 14:59:20 brent has joined #did 14:59:21 Has the meeting connection info been updated? The one I'm using in my calendar isn't working today. 14:59:39 meeting link: https://mit.zoom.us/j/723584251 15:00:07 Thanks, I was unaware we had switched to Zoom for these meetings as well. Is it always the same link? 15:00:22 justin_r: yes 15:00:28 markus_sabadello has joined #did 15:00:37 paulmadsen has joined #did 15:01:05 https://mit.zoom.us/j/723584251 15:01:24 present+ 15:01:35 present+ 15:01:37 present+ 15:01:42 present+ 15:01:46 present+ 15:01:58 phila has joined #did 15:02:00 kdenhartog has joined #did 15:02:03 present+ 15:02:47 Orie has joined #did 15:03:00 dmitriz has joined #did 15:03:54 Tom_S___USAA_ has joined #did 15:04:06 JoeAndrieu has joined #did 15:04:59 selfissued has joined #did 15:04:59 scribe: manu 15:05:08 present+ 15:05:14 present+ 15:05:15 scribe+ 15:05:19 scribe+ manu 15:05:23 q+ 15:05:42 brent: Going over agenda, cover what Formal Objections means, virtual F2F, a couple of straw polls, then PR, then status check of issues. 15:05:46 Can we get an updated calendar invite with the correct meeting link? 15:05:49 brent: any updates/additions to the Agenda? 15:05:52 ack selfissued 15:06:07 q+ 15:06:15 selfissued: I'd appreciate it if schedule invitation links were sent out to new calls, last schedule has WebEx address which no longer works. 15:06:19 ack ivan 15:06:55 Ivan: The problem is that what Zoom produces and that I could forward to everyone has two flows in it, I can only make it for a year, have to renew in a year, and other issue is that this lounge that we have here, will be used for everything that DID WG wants. 15:07:05 present+ 15:07:10 Ivan: I can send out calendar for weekly calls, but it's also same call time. 15:07:21 s/same call time/same call number for other special calls/ 15:07:33 selfissued: Not having it in calendar greatly decreases possibility of people finding it. 15:07:52 Topic: Introductions / Reintroductions 15:07:58 brent: Any new folks on the call today? 15:08:18 tim: Hi Tim Capelli, just joined team w/ Daniel and Microsoft, Decentrlaized is one of my focuses. 15:08:19 identitywoman has joined #did 15:08:47 burn has joined #did 15:09:24 identitywoman: My name is Kaliya Young, handle is Identity Woman, been working on identity for 15+ years. I work for Wireline working on decentralized networks, trying to bridge between decentralized networks and this work. 15:10:15 identitywoman: For example, scuttlebutt uses public keys for everyone in their network, don't know if that's the best thing or not. We have the 30th IIW, it's virtual, same format that we always have, open space, and if you haven't come and want to, nows your chance because you don't have to fly this year. 15:10:20 Topic: Special Topic Call 15:10:44 present+ 15:10:48 present+ 15:10:49 present+ 15:10:49 brent: Next special topic call is this Thursday noon eastern time... 15:11:01 joel has joined #did 15:11:02 brent: That's April 9th, 12pm ET - special topic call. 15:11:06 Topic: What is a Formal Objection? 15:11:08 present+ 15:11:20 present+ 15:11:28 burn: Just wanted to talk a bit about formal objection, people have used that term on calls a few times, people might not be clear about what that means. 15:11:56 burn: A formal objection is a step and action that your company, your W3C Member Organization, would take if it's at the point where they'd block the specification from proceeding. 15:12:14 burn: This is a statement the entire W3C Membership that you object for a specification to proceed. 15:12:17 Eugeniu_Rusu_Jolocom has joined #did 15:12:55 burn: We usually don't ask that unless there seems to be a strong objection about something. A formal objection is a last ditch effort - official step taken by your organization, toward end of process. 15:13:02 q? 15:13:05 dbuc has joined #did 15:13:07 LOL https://www.youtube.com/watch?v=bOnRHAyXqYY 15:13:15 Topic: Virtual F2F Meeting 15:13:35 drummond has joined #did 15:13:40 Eugeniu_Jolocom has joined #did 15:13:49 brent: We have been thinking of organizing a virtual F2F meeting, would people be interested in attending something like that? It would probably consist of 2-3 hours of meetings 2-3 days in a row. 15:13:54 present+ 15:13:56 present+ 15:13:58 q+ 15:14:02 I'd be there as much as I could, sure 15:14:09 present+ 15:14:14 present+ 15:14:30 ack drummond 15:14:44 drummond: Yes, sounds like a good idea. IIW is doing this - 80% of value of being there, if they can do that there, we can certainly do it for a F2F. 15:14:46 Mask2Mask 15:14:50 q+ 15:15:10 and drinks! :-) 15:15:14 timcappalli has joined #did 15:15:14 brent: we'll look into details and chairs will begin planning. 15:15:15 dezell has joined #did 15:15:15 Forget the snacks, who is sponsoring my at-home booze? 15:15:22 q? 15:15:56 ack manu 15:16:08 manu: the virtual f2f - +1 especially if it's only 2-3hrs out of the day. I do want to be sensitive for people beign all zoomed out 15:16:16 TOO MUCH ZOOM 15:16:18 "Zoomed out" is a real thing 15:16:20 present+ 15:16:22 ... I've spoken with a number of people in the wg saying the number of viirtual things they're participating in has skyrocketed 15:16:24 ... we should keep that in mind 15:16:29 rusu_eugeniu_jolocom has joined #did 15:16:31 ... the other concern I have is we need a good agenda 15:16:34 present+ 15:16:44 ... and so my hope is that we have some fairly concrete things to work through 15:17:01 ... I'm at a bit of a loss, I don't know how much progress we'd make if we had those calls like we've been having the special topics call and we've been making progress there 15:17:05 ... just raising those as concerns 15:17:16 ... people are getting a bit burnt out by the amount of teleconferencing they're having to do 15:17:21 ... adding another 8 hours in a week doesn't sound like fun 15:17:24 q+ 15:17:26 q+ 15:17:29 ... but if that's what's needed to get the work moving forward, let's do that 15:17:34 ack burn 15:17:54 q+ 15:18:00 burn: while I understand the complaint about zoom, the intent is that it would replace a f2f, it would be replacing yoru other zoom call just like if you were at a f2f, your participation would be replacing other meetings 15:18:07 ack drummond 15:18:08 ... but if we don't need a meeting, we won't have a meeting. 15:18:10 burn: Just wanted to say that while I understand the complain about Zoom, the intent here is to replace a F2F meeting, should replace your other Zoom calls. Participation would be replacing other meetings at that time. Obviously, if we don't need a meeting, we won't have a meeting. 15:19:14 drummond: Wanted to speak in favor of ... trajectory of specs, in Amsterdam, breaking back of biggest problems, take remaining issues, give sufficient energy to break through whatever blockers are to that. Organize work for whatever work becomes, final push to finish complete draft that goes into next stage. 15:19:14 q? 15:19:19 q+ 15:19:25 drummond: I think it's something we need to do - 3 hours a day doesn't have to be disruptive. 15:19:32 ack selfissued 15:20:49 selfissued: Something for the Chairs to think about, based on, trying to have IETF BOF to create new WG - the huge difference between doing that virtually is that when you're F2F, you can read people's body language and get a sense w/o having official questions, know what people are thinking. In AMS Brent and Dan used that to great benefit... tried to steer conversation in productive directions. Virtual F2F will miss that, which is essential to making that work at 15:20:49 all. I'm not opposed to doing it, but Brent, Dan, you're going to have to come up w/ a mechanism to replace that. 15:21:01 twinkle hands :) 15:21:01 selfissued: I sure hope it isn't +1/-1 in IRC, otherwise, not nearly productive. 15:21:06 manu: I agree w/ Mike. 15:21:07 zakim, who is here? 15:21:08 Present: rhiaro, brent, manu, paulmadsen, dlongley, kdenhartog, selfissued, ivan, yancy, Tom_S___USAA_, justin_r, burn, joel, identitywoman, drummond, Eugeniu_Jolocom, phila, dbuc, 15:21:12 ... JoeAndrieu, timcappalli 15:21:12 On IRC I see rusu_eugeniu_jolocom, dezell, timcappalli, drummond, dbuc, joel, burn, identitywoman, selfissued, JoeAndrieu, Tom_S___USAA_, dmitriz, Orie, kdenhartog, phila, 15:21:12 ... paulmadsen, markus_sabadello, brent, justin_r, RRSAgent, Zakim, ivan, llorllale, chriswinc, dlongley, loveish, manu, dlehn, deiu, hadleybeeman, jfishback, Travis, yancy, 15:21:13 ... ChristopherA, bigbluehat, wayne, rhiaro 15:21:29 selfissued: It's hard to get consensus w/o body language. 15:21:41 brent: Yes, other helpful parts are side discussions / hallway discussions. 15:21:42 yeah, having dialled in to real f2fs, there's a lot missing 15:21:44 q? 15:21:48 ack JoeAndrieu 15:21:58 +1 to Brent's point about the most productive part of F2Fs is between the sessions 15:22:14 JoeAndrieu: Not a matter of if, juts a matter of when -- we don't know how long this will impact appropriateness of international travel, I don't think there's any rush to have one. 15:22:27 it is likely to be a long long time 1-2 years. 15:22:28 manu: +1 no rush to have one. 15:22:35 Thanks all - just looking for group feedback 15:22:46 Topic: Straw Poll for DID Parameters / Matrix Parameters 15:22:49 present+ dmitriz, JoeAndrieu, tim, 15:22:59 https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-04-01-did 15:23:01 manu: we have had a number of calls at this point talking about did parameters and matrix parameters 15:23:21 ... our last call, we had a pretty sharp drop off of people participating to the point where we really couldn't make a definitive decision to put forward to the group so we're bringing it to the group now 15:23:23 jonathan_holt has joined #did 15:23:33 ... there was general agreement that we're going to support did parameters, they are in scope for the wg 15:23:39 ... if you disagree with that you should really let it be known 15:23:44 ... but the time to disagree with that has passed 15:23:51 ... what we're trying to figure out now is if matrix params will be in there or not 15:24:03 ... there seemed to be more support for using query param syntax vs using matrix param syntax for encoding did parameters 15:24:04 present+ markus_sabadello, orie 15:24:11 ... but when we called the question there were only 5 people weighing in, not enough 15:24:18 ... today on the call we need the group to weigh in on an official basis 15:24:40 ... if you don't know what's going on, i'm deferring to the chairs, but I'd really prefer you do not weigh in and tilt the conversation because it would be an unedcuated vote and those can be very helpful 15:24:43 s/helpful/harmful 15:24:52 ... if you have been following the dicsussion, we need you to weigh in 15:25:04 ... there were two proposed resolutions on the previosu call, we're going to put them forward again now 15:25:08 ... after we get any clarifying questions 15:25:18 ... I'm going to emote those in the irc channel so people kno wwhat's coming up 15:25:32 q+ 15:25:35 ... we will be looking for people to +1/-1 them 15:25:42 ... any questions, concerns? 15:25:47 ack markus_sabadello 15:26:05 markus_sabadello: to clarify, manu I think the first proposal doesn't say that query params would be removed, right? says there will be matrix params AND query params 15:26:12 ... the second propsal says there will be only query params 15:26:18 q+ 15:26:22 manu: I can change the proposal, I thought we were going to call the same ones 15:26:22 q+ 15:26:31 markus_sabadello: it's fine, just so people kno wthe first one doens't imply query params are going to be removed 15:26:36 manu: do the chairs agree? 15:26:46 brent: I'm fine either changing it or leaving it the same, as long as that's the meaning of the first one 15:26:57 ... the first proposal is not to remove anything, it would be to use matrix param syntax for encoding did params 15:27:00 Just change it, so we don't have some inferred understanding 15:27:08 ... if the group prefers more clarified language then do that 15:27:19 q? 15:27:21 manu: updated proposal 15:27:23 ack drummond 15:27:59 drummond: i want to make sure that folks that are not as deep into this but still would have an opinion about it, if the terminology is clear? when using the term DID parameters, we're talking about any form of params for dids, whether they're encoded in the query string or the authority component with the ; syntax (in the spec today) 15:28:11 ... when we're talking about matrix parameters we're just talking about the authority component semicolon 15:28:17 ... query params are a special encoding in the query string 15:28:21 ... DID parameters are any of the above 15:28:23 ack JoeAndrieu 15:28:23 q+ 15:28:36 JoeAndrieu: I was surprised to see these two exactly as presented because there was pushback structurally on the last call 15:28:47 ... there isn't the option to support query parameters without reserving matrix parameters 15:28:52 ... I'd like to see the third option on the table 15:28:56 manu: could you type that? 15:28:57 JoeAndrieu: yep 15:29:05 ack markus_sabadello 15:29:12 markus_sabadello: I don't want to confuse people even more but my understanding of the DID parameters was different than what drummond said 15:29:28 third proposal: Use query parameter syntax for encoding DID Parameters, making no statements about matrix parameter characters at this time 15:29:33 ... in my mind DID parameters are ones that we as the WG/registry maintainers specify and that have known behaviour for the did resolution process, things like service selection, versioning and so on 15:29:37 q+ 15:29:43 ... these ones are did parameters which right now are encoded using matrix parameters, the proposals are about that 15:29:48 I think there's a simpler way to convey this 15:29:58 ... we also have query params that are not specified by the WG but are up to the developers and users 15:30:04 yes 15:30:06 exactly 15:30:23 ... in my mind the DID parameters are the ones we as the WG define and control, and the question is whether those are expressed as matrix or query parameters, with the understanding that there are other parameters that are left to the user 15:30:38 brent: this is turning into more of a discussion... come to our call on thursday where we will talk about this 15:30:45 ack dbuc 15:31:16 dbuc: when they say using url parameters for DID parameters, at the top level of your string all the parameters will be resolution-used parameters. They'll be stripped out and used by the process of resolution. Everything left is a DID parameter, even if it's not in the specification but tacked on as a method to do something 15:31:23 ... the top level string, all the parameters are for the DID itself 15:31:48 brent: are we ready for a straw poll? 15:32:00 yes 15:32:08 no 15:32:31 +1 to an exhaustive example: did:example:21tDAKCERh95uGgKbJNHYp;service=agent;foo:bar=high/mypath?myquery#myfragment 15:32:45 manu: in general this is about expressing the DID parameter, the syntax for expressing the DID param is what we're talking about 15:32:51 ... we're not talking about if they exist, but how we type them out 15:33:00 ... one option is matrix params, the other is query params, that's what we're trying to figure out 15:33:08 ... do the chairs feel comfortable calling this quesiton? it has been dragging out for 3 weeks 15:33:13 ... but it looks like people may still be confused 15:33:28 brent: the goal of this topic during this meeting today wa sa straw poll to guage the gneeral opinions of the group in order to inform the discussion moving forward 15:33:31 ... not to achieve any sort of final resolution 15:33:39 not confused, let's just vote - we could probably chase our tail on this for weeks/months more 15:34:00 manu: joe, does yours need to go in a certain order? 15:34:05 JoeAndrieu: if all three are to be considered as options that's fine 15:34:37 JoeAndrieu: the point was to separate the decision to use matrix params from the decision to use query params 15:34:51 ... reserving matrix params when we don't have a use for them seems to be a seperable issue 15:35:01 PROPOSAL: Use matrix parameter syntax for encoding DID Parameters with the possibility of also using query parameters. 15:35:04 +1 15:35:05 -1 15:35:05 manu: -1 15:35:07 -1 15:35:09 0 15:35:11 -1 15:35:11 +1 15:35:11 -1 15:35:13 -1 15:35:14 0 15:35:15 0 15:35:15 -1 15:35:16 -1 15:35:19 0 15:35:28 -1 15:35:34 0 15:35:56 manu: seeing -1s and 0s, not a lot of +1s 15:36:03 3 are from our org - have to say that just to be legit about things 15:36:21 PROPOSAL: Use query parameter syntax for encoding DID Parameters, making no statements about matrix parameter characters at this time 15:36:37 manu: note we have another one coming that does make statements about matrix params 15:36:40 +0.4 15:36:40 -1 15:36:42 +1 15:36:42 -1 15:36:47 +1 15:36:48 dbuc: what would the effect of this be? 15:36:49 unclear 15:36:51 -1 15:36:52 +1 15:36:52 +1 15:36:55 manu: this says we're not going to reserve matrix params 15:36:57 -1 15:36:58 ... the next one reserves them 15:36:58 +1 15:36:59 +1 15:37:01 0 15:37:02 -1 15:37:14 sorry, i'll go 0 to abstain 15:37:36 manu: almost half and half 15:37:58 PROPOSAL: Use query parameter syntax for encoding DID Parameters, reserving matrix parameter characters for possible use in a future specification. 15:38:02 +1 15:38:02 +1 15:38:03 +1 15:38:03 +1 15:38:04 +1 15:38:05 +1 15:38:09 +1 15:38:10 +1 15:38:11 -1 15:38:12 0 15:38:13 0 15:38:15 ... this says we're going to use query params for DID params but in case we make a mistake we can use matrix params in the future 15:38:15 0 15:38:16 +1 15:38:19 +1 15:38:31 0 15:38:40 manu: joe do you want to talk to your -1? 15:38:45 JoeAndrieu: I already did. Happy to go with consensus 15:38:50 manu: this is looking like this is where consensus is 15:39:01 ... do chairs want to call it or give 7 days? and we can start putting in PRs for this approach 15:39:09 brent: call it 15:39:17 RESOLVED: Use query parameter syntax for encoding DID Parameters, reserving matrix parameter characters for possible use in a future specification. 15:39:33 manu: we have 7 days for people not on the call to object and hopefully bring new evidence on why they're objecting 15:39:36 what issue tracks this resolution? 15:39:39 ... This clarifies what the editors need to do as a next step 15:39:45 https://github.com/w3c/did-core/issues/159 15:39:51 q+ to an unrelated admin 15:40:00 TOPIC: Markus introduces a PR for comments 15:40:01 Topic: DID Resolution Contract PR 15:40:09 s/TOPIC: Markus introduces a PR for comments// 15:40:10 s/Topic: DID Resolution Contract PR// 15:40:23 ack ivan 15:40:23 ivan, you wanted to an unrelated admin 15:40:27 Topic: DID Resolution Contract PR 15:40:35 PR about DID Resolution: https://github.com/w3c/did-core/pull/247 15:40:39 q+ 15:40:41 brent: Let's take some time to discuss this PR... 15:41:24 ivan: Regarding DID WG meetings - quick side bar - don't use Zoom invite, please use the previous calendar invite I sent out. 15:41:29 Ivan, can you please send a brand new email to the members' list with the zoom room, etc? 15:41:30 ack selfissued 15:41:58 selfissued: Can't you use calendaring system, create manual recurring invitation, then send to WG members list? 15:42:17 ivan: not sure Apple calendar invite would work for everyone, created more problems than not. 15:42:21 It's true that an Apple calendar invite has interop issues 15:42:28 selfissued: Can someone create it and send it out to the WG? 15:42:40 brent: I will look into it. 15:43:35 markus_sabadello: Just pasted link to new PR about DID Resolution, based on two action items, two topics that came out of F2F meeting... one of the topics was DID Resolution, general sense at F2F meeting that some parts of what is currently covered by DID Resolution spec, not in DID WG in CCG, that some content from that document should be in scope for DID Core spec. 15:44:22 markus_sabadello: Interface, DID Resolution... what are inputs, outputs, data structures that we want. From time to time we've had discussions in DID Core spec instead of DID Resolution in more detail. What's the point of defining DID Parameters if you can't do that in resolution? 15:45:23 markus_sabadello: The group wanted to include the contract... DID Resolution, Dereferencing... second topic at F2F is entire metadata discussion, when we have DID Documents but also have certain other pieces of data, didn't know what to do with them, had this Google Doc at F2F meeting, collected properties, proofs, and other things, had ongoing discussion on go into DID Document or other data structures should go. 15:45:41 markus_sabadello: We've been trying to discuss what different buckets for those pieces of data should be. 15:45:46 https://github.com/w3c/did-core/issues/65#issuecomment-597030882 15:46:18 markus_sabadello: This attempts to discuss metadata discussion and DID Resolution discussion, PR 247 - adds content to two sections in DID Core spec. 15:46:35 markus_sabadello: these sections have been empty to date, one of that section, DID Resolvers/Resolution - section 3 - overall architecture. 15:46:48 I wasn't asking for a hand-crafted ical file, per se. I was asking for a working calendar invitation - to help all the WG members join the calls. 15:47:09 markus_sabadello: subsection called did resolvers/resolution - PR proposes content there - stating that DID Resolution isn't a concrete protocol... abstract function that can be implemented in different ways - second section, filled by PR -- section 10 15:47:31 If Ivan and the chairs can't find a way to do it, as a worst case, I'll create a calendar invitation myself in Outlook and send it to the WG members list. 15:47:31 q+ 15:48:01 But I hope the chairs and Ivan can do this rather than me as an individual WG member 15:48:11 markus_sabadello: Resolution section has sections that PR adds, resolving a DID, dereferencing... PR doesn't specify concrete data formats or protocols, abstract functions. Subsections about resolver options and metadata. Doesn't try to define what data structures look like, JSON, CBOR, how do you express metadata in concrete network protocol, PR doesn't say that, just says what buckets of metadata are and implements different ways. 15:48:33 markus_sabadello: There have already been two -1 comments, suggestions, justin added some fixes/improvements that I've incorporated. 15:48:48 markus_sabadello: given that it's significant to input to spec, it would be good to have more discussion and review. 15:48:50 +q 15:49:01 Nice work, Markus! 15:49:04 This document is a starting strawman just to get discussion going 15:49:09 I see text like Implementation details and a concrete algorithm for this function can be found in [[?DID-RESOLUTION]]. 15:49:12 ack phila 15:49:19 q+ 15:49:29 phila: If I were Ivan, I wouldn't let this PR happen - there are multiple sections that are normative in core spec that talk about resolver as this as input, that as output, that's very close to a specification. 15:50:18 phila: As copy in there, it talks about non-normative to normative pointer... we shouldn't pretend that we're not putting in details of resolution. I'm considering formal objection on this, it's bad that we got into this state, either we make this normative, or it's taken out. 15:50:21 ack justin_r 15:50:41 justin_r: From my perspective, this is really a good start at getting at things we talked about in AMS - it's not fully polished, moving in right direction. 15:50:43 I have to say I agree with Phil that we need to pull resolution into scope at some point. 15:51:23 justin_r: I do think it's viable to have the definitions of the functions in the spec w/o getting into the details. There are parts of this PR that go into too much detail, and parts that don't go into enough detail. I'm trying to correct those w/ PRs. Think we can do a little bit more. 15:51:26 q+ 15:52:16 q+ 15:52:30 justin_r: For example, a little too much said on "binding". The notion of what a binding is and what a binding has to define is important, need that in order to reference this. I do think these bits should be normative - my suggestions was to make this stuff MUSTs instead of SHOULDs. Important to define what resolution output is combination of input+resolution output. 15:52:44 justin_r: What I'mc alling dereferencer/resolver, get metadata, expect it in a particular form. 15:52:50 ack markus_sabadello 15:53:45 markus_sabadello: Just to also confirm, this is meant to be a start - things to be improved, formal mistakes - non-normative section referencing normative section... trying to understand if this is completely wrong, workable, good direction? Should Resolution be completely out of scope? Or should it be in scope? 15:54:13 markus_sabadello: At F2F Meeting, thought we wanted something inbetween... what do we want? I don't have a strong opinion, could work either way. Attempt to capture where consensus was. 15:54:42 ack manu 15:54:46 brent: This is a good start, if you want tex to be different, propose different text. 15:54:47 We have a lot of open PRs with approvals... and a few old / stale PRs with changes requested... 15:54:49 q+ to encourage people to have discussion, as we are, not to make absolute statements cutting off discussion, and that PR likely won't go in anything like it is 15:54:54 manu: I think it's a good start 15:55:02 ... I share phil's concern and I also share justin's concern 15:55:07 ... and I think that's why we tried to do something in the middle 15:55:19 ... if we start talking in a strongly normative way about the resolution process I think that's going to be a problem 15:55:23 ... resolution is not in scope for the wg 15:55:29 ... it's not in our charter, I know some disagree 15:55:39 ... speaking as an editor, it expands our scope beyond what the group signed up to do 15:55:54 ... but at the same time I do agree that having some language in there to talk about resolution is helpful, as long as we don't go too far down the normative rabbithole 15:56:12 ... there is also a strong argument for pointing to the did resolution spec in a non-normative way and saying you need to understand did resolution and this document explains it 15:56:25 ... we can't use that language in the spec, i think phil would agree with that more? i would be more comfortable with that 15:56:40 ... to be clear, I think markus has done really good work, I don't think the tetx is going to be destroyed, it's just where should it belong 15:56:47 ... that's going to be a discussion we end up having over the next couple of weeks 15:56:52 .... I don't think this needs to turn into an all or nothing thin 15:56:56 q+ 15:56:59 ... we just need to strike a balance 15:57:03 ack kdenhartog 15:57:04 ... please put comments in the PR 15:57:59 ack burn 15:57:59 burn, you wanted to encourage people to have discussion, as we are, not to make absolute statements cutting off discussion, and that PR likely won't go in anything like it is 15:58:02 kdenhartog: as someone who has implemented resolution based on that spec, the thing I have cared about most is the context. What i should be doing with the DID vs what I should be doing with the DID URL. I liked how we were defining it with the use of a contract, and liked the drection it was headed. Why can't we define the contract to say when you pass in a DID here's what you get, and when you pass a DID URL here's what youget, and turn the DID 15:58:02 resolution spec into an implementation guide 15:58:06 kdenhartog: Speaking from perspective on someone that's implemented resolution, the thing I've cared about most is the contract -- what should I be doing w/ the DID vs. DID URL, that's why I liked how we were defining it w/ contract - question is: Why can't we define contract to say "when you pass in DID, here's what you get..." then change DID REsolution spec into an implemention guide. 15:58:47 burn: Manu said some of what I wanted to, but we need to be careful about formally objecting. 15:59:14 burn: I think we are having a proper discussion about what belongs in this group and what doesn't, this PR is helping us have that discussion. 15:59:15 q? 15:59:39 burn: This PR is probably not going to make it in its current state, we're not going to put in PR that violates charter... but we do want people to have a good discussion about this. 15:59:45 ack markus_sabadello 16:00:17 markus_sabadello: One quick detail, before I did this PR, we already agreed to restructuring of ToC - added two sections w/o adding content - overall architecture - new DID Resolution - please comment on PR, if you disagree on PR and content, or overall structure of spec. 16:00:30 markus_sabadello: Do we disagree w/ content, or having those sections at all. 16:00:56 brent: Thanks all, end of call, see you Thursday noon ET for special call. 16:01:00 rrsagent, draft minutes. 16:01:00 I'm logging. I don't understand 'draft minutes.', manu. Try /msg RRSAgent help 16:01:05 rrsagent, draft minutes 16:01:05 I have made the request to generate https://www.w3.org/2020/04/07-did-minutes.html manu 16:01:10 zakim, end meeting 16:01:10 As of this point the attendees have been rhiaro, brent, manu, paulmadsen, dlongley, kdenhartog, selfissued, ivan, yancy, Tom_S___USAA_, justin_r, burn, joel, identitywoman, 16:01:13 rrsagent, make logs public 16:01:14 ... drummond, Eugeniu_Jolocom, phila, dbuc, JoeAndrieu, timcappalli, dmitriz, markus_sabadello, orie 16:01:14 RRSAgent, please draft minutes 16:01:14 I have made the request to generate https://www.w3.org/2020/04/07-did-minutes.html Zakim 16:01:16 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:01:16 rrsagent, draft minutes 16:01:16 I have made the request to generate https://www.w3.org/2020/04/07-did-minutes.html manu 16:01:19 Zakim has left #did 16:01:35 yes 16:28:44 JoeAndrieu has left #did