14:52:29 <RRSAgent> RRSAgent has joined #did
14:52:34 <RRSAgent> logging to https://www.w3.org/2024/10/10-did-irc
14:52:37 <burn> rrsagent, draft minutes
14:52:38 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/10-did-minutes.html burn
14:52:41 <burn> rrsagent, make logs public
14:59:43 <decentralgabe> decentralgabe has joined #did
15:00:15 <burn> present+
15:00:21 <markus_sabadello> markus_sabadello has joined #did
15:00:50 <decentralgabe> present+
15:01:15 <markus_sabadello> present+
15:02:50 <bigbluehat> bigbluehat has joined #did
15:02:50 <dmitriz> dmitriz has joined #did
15:02:52 <TallTed> TallTed has joined #did
15:04:21 <JoeAndrieu> JoeAndrieu has joined #did
15:04:22 <manu> manu has joined #did
15:04:33 <manu> present+
15:04:40 <Wip> Wip has joined #did
15:04:46 <Wip> present+
15:06:00 <JoeAndrieu> scribe+
15:06:25 <JoeAndrieu> burn: one note: we know the TPAC minutes aren't published. We're working on it.
15:06:34 <JoeAndrieu> ... Apologies
15:06:53 <burn> Topic: Agenda Review, Introductions
15:07:33 <JoeAndrieu> ... A bit of follow up for TPAC. Then we changed the order, swapping the order of resolution and core so we have the opportunity to get through resolution
15:07:54 <burn> q?
15:07:56 <JoeAndrieu> ... Changes or additions?
15:08:01 <JoeAndrieu> [room is silent]
15:08:08 <burn> Topic: Follow-ups from TPAC
15:08:13 <JoeAndrieu> .... Any new folks?
15:08:20 <JoeAndrieu> ... Ok. On to TPAC follow ups
15:08:43 <JoeAndrieu> ... First, we had decided to publish the DID resolution FPWD on a particular date, but there is a publication moratorium on that date
15:08:48 <JoeAndrieu> ... so we'll need to publish later.
15:09:01 <JoeAndrieu> ... Markus, might you have a resolution to propose regarding FPWD?
15:09:23 <markus_sabadello> https://w3c.github.io/did-resolution/transitions/2024/FPWD/
15:09:23 <JoeAndrieu> markus_sabadello: I can do that. We already voted on publishing, but we need to update the date.
15:09:40 <smccown> smccown has joined #did
15:09:45 <JoeAndrieu> ... This is basically the same spec that was voted on, just with a new date. Now Nov 5, 2024.
15:10:21 <JoeAndrieu> ... A little bit of flexibility in those dates
15:10:38 <JennieM> JennieM has joined #did
15:10:44 <JoeAndrieu> ... Adding the short-name
15:11:11 <JennieM> present+
15:11:14 <smccown> present+
15:11:18 <JoeAndrieu> burn: please remember to "present+" in IRC
15:11:21 <JoeAndrieu> present+
15:11:21 <TallTed> present+
15:11:24 <markus_sabadello> Proposed: Publish the document at https://w3c.github.io/did-resolution/transitions/2024/FPWD/ as FPWD at the earliest possible opportunity, aiming for November 05, no later than November 30. The short name will be "did-resolution".
15:11:33 <burn> +1
15:11:33 <manu> +1
15:11:37 <JoeAndrieu> +1
15:11:37 <TallTed> +1
15:11:38 <Wip> +1
15:11:38 <decentralgabe> +1
15:11:40 <markus_sabadello> +1
15:11:47 <smccown> +1
15:11:50 <JoeAndrieu> burn: get your votes in
15:12:00 <burn> Resolved: Publish the document at https://w3c.github.io/did-resolution/transitions/2024/FPWD/ as FPWD at the earliest possible opportunity, aiming for November 05, no later than November 30. The short name will be "did-resolution".
15:12:02 <JoeAndrieu> ... Ok. RESOLVED.
15:12:15 <JoeAndrieu> ... Next item: the publishing of the extension documents
15:12:34 <manu> q+
15:12:38 <burn> ack manu
15:12:39 <JoeAndrieu> decentralgabe: I was hoping PA was going to be here. Might need to break these into three separate specs
15:12:51 <JoeAndrieu> manu: The problem has to do with how publication process goes
15:12:59 <JoeAndrieu> ... We just need to work through the details with PA.
15:13:26 <JoeAndrieu> ... You can't auto publish secondary documents/multiple documents at once
15:13:48 <JoeAndrieu> ... I think we can use the same repo, but would need different echidna setups in different targets. It's doable, we just need to figure it out.
15:14:05 <JoeAndrieu> burn: not sure if we need a resolution, but if you think so, Manu, let's do that
15:14:12 <JoeAndrieu> manu: Yeah, we might need to
15:14:33 <JoeAndrieu> burn: it would permit that as an alternative if we need to
15:14:47 <JoeAndrieu> manu: [mumbling to himself]
15:15:53 <JoeAndrieu> ... [continued mumbling as he writes up the proposal]
15:16:24 <JoeAndrieu> q+
15:16:35 <burn> ack JoeAndrieu
15:16:36 <decentralgabe> scribe+
15:16:50 <decentralgabe> JoeAndrieu: we might need to identify what is each extension list
15:17:10 <decentralgabe> ... it's an echo of the did properties extension just with shorter names
15:17:32 <decentralgabe> manu: we need to be careful with these lists. it's clear what's in DID Methods and DID resolutions
15:19:31 <decentralgabe> JoeAndrieu: my only pushback, each extension list felt ambiguous. I understood what you said as "we want to retain some flexibility" so maybe that's the best tradeoff, what you already have
15:19:39 <manu> q+
15:19:45 <burn> ack manu
15:20:10 <JoeAndrieu> manu: I tried separating did methods
15:21:07 <JoeAndrieu> joe: I'm good with that language
15:21:29 <JoeAndrieu> burn: any other comments on this?
15:21:33 <manu> PROPOSAL: In the event that the did-extensions cannot be published under /TR/did-extensions, the WG approves the publication of each extension list at the following short name locations: did-document-extensions, did-resolution-extensions, and did-methods
15:21:33 <JoeAndrieu> burn: ok, let's run it
15:21:41 <JoeAndrieu> +1
15:21:41 <markus_sabadello> +1
15:21:42 <burn> +1
15:21:42 <decentralgabe> +1
15:21:43 <Wip> +1
15:21:45 <TallTed> +1
15:21:45 <JennieM> +1
15:21:47 <manu> +1
15:21:55 <burn> RESOLVED: In the event that the did-extensions cannot be published under /TR/did-extensions, the WG approves the publication of each extension list at the following short name locations: did-document-extensions, did-resolution-extensions, and did-methods
15:22:03 <bigbluehat> present+
15:22:17 <JoeAndrieu> burn: as the third of the TPAC follow ups, an update here.
15:22:35 <JoeAndrieu> ... there are a number of items the group needs to discuss, including extensions, the rubric, use cases.
15:22:55 <JoeAndrieu> ... We'll provide a 10-15 slot in each meeting where we will rotate through those different items
15:23:09 <JoeAndrieu> ... So every 3-4 weeks each topic will get some time in the regular meeting.
15:23:27 <burn> Topic: DID Resolution Issue/PR Processing
15:23:28 <JoeAndrieu> ... Contact the chairs if anyone would suggest an improvement
15:23:54 <JoeAndrieu> markus_sabadello: let's start with new issues
15:23:57 <markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close
15:24:05 <JoeAndrieu> ... first with pending close issues
15:24:20 <burn> q+
15:24:33 <burn> ack burn
15:24:51 <JoeAndrieu> burn: note that, in the agenda email, we listed these issues.
15:25:17 <JoeAndrieu> ... We'll be using this process until the end of the thursday meeting to object to the close.
15:25:40 <TallTed> I strongly recommend such searches be ordered by "least recently updated" to keep the churn active, e.g., https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close+sort%3Aupdated-asc
15:25:52 <JoeAndrieu> JoeAndrieu has joined #did
15:26:33 <JoeAndrieu> burn: the point is, we'll review these quickly today, but the expectation is that you are too look for these in the agenda and speak up or comment in the issue if you have an objection
15:26:49 <JoeAndrieu> ... so we will not be spending time unless there is a concern (as a general rule)
15:26:55 <markus_sabadello> https://github.com/w3c/did-resolution/issues/57
15:27:07 <JoeAndrieu> markus_sabadello: Proposal to rename one of the resolution functions
15:27:14 <JoeAndrieu> ... Resolve and ResolveStream
15:27:43 <JoeAndrieu> ... This issue is a proposal to rename ResolveStream. That's already happened. I posted a comment 2 weeks ago. No further discussion
15:27:51 <JoeAndrieu> burn: any objections to closing?
15:28:03 <JoeAndrieu> markus_sabadello: I'll close them after the call
15:28:14 <markus_sabadello> https://github.com/w3c/did-resolution/issues/30
15:28:32 <JoeAndrieu> markus_sabadello: Issue 30, several years old. Has to do with dereferencing discussion at TPAC
15:28:48 <JoeAndrieu> ... "The result of dereference can be a DID document, but it can also be something else"
15:29:22 <JoeAndrieu> ... Looking at this issue after a long time, I think the current specification addresses this. I see 3 thumbs up to that comment.
15:29:30 <JoeAndrieu> ... So, if no objections, we'll be closing this.
15:29:31 <markus_sabadello> https://github.com/w3c/did-resolution/issues/29
15:29:46 <JoeAndrieu> markus_sabadello: also several years old, about the definition of the term did resolver.
15:30:19 <JoeAndrieu> ... In the current specification, both terms are defined formally in terminology section. Also two thumbs up.
15:30:25 <JoeAndrieu> ... Any objections?
15:30:26 <markus_sabadello> https://github.com/w3c/did-resolution/issues/21
15:30:48 <JoeAndrieu> markus_sabadello: Issue 21 about removing the term DID Reference from DID core to DID Resolution.
15:31:04 <JoeAndrieu> ... I think this is now obsolete. We don't use that term in any spec.
15:31:19 <JoeAndrieu> ... Same discussion was also in did-core, which was closed. So I think this one can be as well.
15:31:26 <JoeAndrieu> ... Any objections?
15:31:28 <markus_sabadello> https://github.com/w3c/did-resolution/issues/11
15:31:34 <brent> brent has joined #did
15:31:44 <JoeAndrieu> markus_sabadello: All methods must have a name of at least three characters.
15:32:04 <JoeAndrieu> ... This seems like a DID Core issue, not in DID Resolution
15:32:15 <JoeAndrieu> ... Similar issue in DID-core, which has also been closed.
15:32:33 <JoeAndrieu> ... For all of these issues, it seems straightforward to close them.
15:32:51 <burn> q+
15:32:58 <JoeAndrieu> ... Since they are older issues, we may not be getting engagement from the initial poster, but unless there are objections, seems like we should close
15:33:13 <burn> ack burn
15:33:21 <JoeAndrieu> decentralgabe: If we mark it pending close and give it a week, that would address the older participants
15:33:58 <JoeAndrieu> burn: requirements vary from group to group. In past groups, we've made the point to actively reach out by email and ask for engagement. Then you can comment that in the issue.
15:34:13 <JoeAndrieu> ... so ping in the issue, then email, then document that email in the issue.
15:34:28 <JoeAndrieu> ... That let's us show we've done what we can to address the concerns of the original poster
15:34:42 <JoeAndrieu> ... For these, I think we're good, but going forward that's a nice improvement to our process
15:34:58 <JoeAndrieu> burn: you have 10 more minutes if you like
15:35:04 <markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
15:35:13 <JoeAndrieu> markus_sabadello: one other thing. A few issues are tagged as "Good First Issue"
15:35:23 <JoeAndrieu> ... Two of them have been assigned. One has not.
15:35:48 <JoeAndrieu> ... These are a good way to contribute, especially if you might not be familiar with deeper technical issues.
15:36:12 <JoeAndrieu> ... We'll try to find more like that and encourage PRs
15:36:48 <JoeAndrieu> ... A few that might be ready to close
15:36:51 <markus_sabadello> https://github.com/w3c/did-resolution/issues/23
15:37:07 <JoeAndrieu> ... Issue 23 is about result of dereferencing
15:37:21 <manu> q+
15:37:34 <JoeAndrieu> q+
15:37:43 <manu> q- later
15:37:49 <burn> ack JoeAndrieu
15:39:38 <manu> JoeAndrieu: Looking at the backlog. There is an opportunity here to make a distinction -- how we talk about a DID with and without a trailing slash... but I don't know if that helps us. I need to look at this in more detail, it's five years old, we can close it, if problem still exists, we can raise a new issue again.
15:39:39 <dlehn> dlehn has joined #did
15:39:48 <manu> markus_sabadello: I think this might be obsolete by now?
15:39:53 <manu> JoeAndrieu: Yeah, sounds like it might be.
15:40:06 <manu> markus_sabadello: We will have until next call to look at it or raise a new issue if this comes back.
15:40:09 <manu> JoeAndrieu: Sounds good to me.
15:40:25 <burn> q?
15:40:27 <burn> ack manu
15:40:48 <JoeAndrieu> manu: I'm wondering what is the ... I'm fine with closing it. I'm wondering where did we land?
15:41:06 <JoeAndrieu> ... the response from a resolver is a resolution result, which might contain a did document?
15:41:11 <JoeAndrieu> ... Is that where we landed?
15:41:36 <JoeAndrieu> markus_sabadello: that's right the resolution response might contain a did document, but dereferencing might return something else
15:42:00 <JoeAndrieu> manu: i think it's already addressed (as opposed to an older issue that isn't valid)
15:42:18 <JoeAndrieu> markus_sabadello: this was from when we didn't have a did resolution result, we were just returning DID documents
15:42:25 <JoeAndrieu> ... That has been addressed
15:42:31 <JoeAndrieu> +1
15:42:33 <JoeAndrieu> manu: +1
15:43:14 <JoeAndrieu> markus_sabadello: also to be aware of, from discussions at TPAC, when we talked about path, query, and fragment parts.
15:43:36 <JoeAndrieu> ... we talked about different patterns in the past and how much of that should be in the resolution spec itself or in did core, or in both.
15:43:56 <JoeAndrieu> ... If people come up with certain features that use the path or query string, how does that fit in and where does it get specified?
15:44:08 <markus_sabadello> https://github.com/w3c/did-resolution/issues/85
15:44:10 <JoeAndrieu> ... There are two open issues for new DID parameters with certain functionality
15:44:15 <markus_sabadello> https://github.com/w3c/did-resolution/issues/90
15:44:54 <JoeAndrieu> ... The first introduces version-type the second XYZ as parameters
15:45:24 <JoeAndrieu> ... Please comment about where these should go and whether or not it should be did-method-specific or standardized across methods
15:45:46 <JoeAndrieu> burn: ok, you have about another 5 minutes if you'd like
15:46:10 <JoeAndrieu> markus_sabadello: ok. I'm wondering if we can merge that pull request
15:46:11 <markus_sabadello> https://github.com/w3c/did-resolution/pull/89
15:46:26 <JoeAndrieu> ... or if anyone has new thoughts about the discussion we had about primary resource and secondary resource
15:46:44 <JoeAndrieu> ... there is an open PR where I tried to improve the headings
15:46:58 <JoeAndrieu> ... to help with that. I'm wondering if people have opinions.
15:47:10 <JoeAndrieu> ... I would actually prefer not to merge because it makes the headings longer
15:47:18 <manu> q+
15:47:27 <JoeAndrieu> ... But the algorithm talks about dereferencing the primary resource and secondary resource
15:47:39 <JoeAndrieu> ... This PR adds explanation to the headings
15:47:47 <burn> ack manu
15:48:13 <JoeAndrieu> manu: I think it is unfortunate that the initial wording was primary and secondary resource, as that is so abstract it is confusing.
15:48:31 <JoeAndrieu> ... +1 to comment about section titles get hard
15:48:53 <TallTed> +1 to manu's suggestion
15:49:10 <JoeAndrieu> ... maybe we can call it derereferencing a DID? or a #fragment
15:49:29 <JoeAndrieu> ... +1 to not merge this, but maybe we can have did document and fragment as the terms
15:50:00 <JoeAndrieu> markus_sabadello: there is something that right now is called a primary resource.
15:50:21 <manu> q+
15:50:25 <JoeAndrieu> ... there needs to be a name for what you get when you dereference the did document
15:50:39 <burn> ack manu
15:50:41 <JoeAndrieu> ... For example, dereferencing the DID URL resource may be a better phrase
15:51:00 <JoeAndrieu> manu: yes. that was my thinking. Name the types of things you can dereference.
15:51:36 <JoeAndrieu> ... A use case where you get a DID Document. A case where you dereference a fragment in a resource. And a third case where it's neither of those.
15:51:56 <JoeAndrieu> ... Related Resource? (Not suggesting that, but if we name it, it will help)
15:52:32 <JoeAndrieu> markus_sabadello: this needs to be extensible. we can't imaging all the things they dereference to.
15:52:43 <JoeAndrieu> ... but i think we can use better terms than Primary & Secondary. I'll try to do that.
15:52:49 <JoeAndrieu> q+
15:52:55 <burn> ack JoeAndrieu
15:53:11 <manu> JoeAndrieu: I would like to try my hand at writing this PR, don't know when I'm going to get to it, but want to help.
15:53:32 <burn> Topic: DID Core Issue/PR Processing
15:53:34 <JoeAndrieu> burn: ok. Excellent. Manu, you have a pending close issue
15:53:51 <JoeAndrieu> burn: issue 862.
15:54:02 <burn> https://github.com/w3c/did-core/issues/862
15:54:28 <JoeAndrieu> manu: it's working. This is fixed.
15:54:32 <JoeAndrieu> ... so we can close
15:54:59 <JoeAndrieu> manu: any objections to closing?
15:55:07 <JoeAndrieu> [room is silent]
15:55:14 <manu> subtopic: https://github.com/w3c/did-core/issues/863
15:55:24 <JoeAndrieu> manu: something to think about. Issue 863 about our media type
15:55:37 <JoeAndrieu> ... We should reconsider application/vc and application/vp
15:56:31 <JoeAndrieu> ... We had a conversation with TAG, when you are using JSON-LD and it could also be JSON, we'd feel better if the spec says ANY interpretation cannot be different between the two. Any difference is either a specification bug or an implementation bug.
15:56:45 <JoeAndrieu> ... This feels like it addresses some outstanding confusion.
15:57:06 <JoeAndrieu> ... In which case we can just be application/did
15:57:16 <JoeAndrieu> ... but fundamentally, no software system should interpret one over the other.
15:57:32 <JoeAndrieu> ... I'll bring this up again the next time we discuss the issue
15:57:41 <JoeAndrieu> burn: Any other items?
15:57:46 <JoeAndrieu> burn: Thanks everyone
15:58:02 <manu> rrsagent, draft minutes
15:58:04 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/10-did-minutes.html manu
16:22:42 <dmitriz> dmitriz has joined #did
18:01:59 <Zakim> Zakim has left #did
18:48:26 <TallTed> RRSAgent, bye
18:48:26 <RRSAgent> I see no action items