14:52:58 <RRSAgent> RRSAgent has joined #did
14:53:03 <RRSAgent> logging to https://www.w3.org/2025/09/04-did-irc
14:53:05 <ottomorac> rrsagent, draft minutes
14:53:07 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/04-did-minutes.html ottomorac
14:53:22 <ottomorac> rrsagent, make logs public
14:53:23 <ottomorac> Meeting: Decentralized Identifier Working Group
14:53:25 <ottomorac> Chair: <IRC NAME>
14:53:29 <ottomorac> Agenda: <link to agenda>
14:53:45 <ottomorac> s/Agenda: <link to agenda>//
14:53:57 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Sep/0001.html
14:54:16 <ottomorac> s/Chair: <IRC NAME>//
14:54:25 <ottomorac> Chair: ottomorac
14:54:51 <ottomorac>  rrsagent, draft minutes
14:54:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/04-did-minutes.html ottomorac
15:00:45 <ivan> present+
15:01:25 <Wip> Wip has joined #did
15:01:27 <JoeAndrieu> JoeAndrieu has joined #did
15:02:05 <pchampin> present+
15:02:11 <ottomorac> present+
15:02:27 <KevinDean> KevinDean has joined #did
15:02:31 <KevinDean> present+
15:03:36 <bigbluehat> bigbluehat has joined #did
15:03:56 <bigbluehat> scribe+
15:04:26 <bigbluehat> ottomorac: today we'll be looking at a few PRs
15:04:43 <bigbluehat> ... we'll also look at POST method use
15:04:52 <bigbluehat> ... and dereferencing
15:05:00 <bigbluehat> ... there's another issue around handling relativeRef
15:05:08 <bigbluehat> ... and there are some other issues if we have time
15:05:13 <bigbluehat> ... anything need adding?
15:05:24 <ottomorac> Topic: DID Resolution PR Processing
15:05:34 <markus_sabadello> markus_sabadello has joined #did
15:05:34 <ottomorac> Add NO_CACHE_DISALLOWED error #183https://github.com/w3c/did-resolution/pull/183
15:05:35 <ottomorac> Add direct links to did extensions #184https://github.com/w3c/did-resolution/pull/184
15:05:46 <bigbluehat> ottomorac: we have 2 new PRs from my side
15:05:46 <Wip> present+
15:05:50 <bigbluehat> ... these are both fairly simple
15:05:57 <manu> present+
15:06:11 <JoeAndrieu> present+
15:06:13 <bigbluehat> ... one is just a reference fix
15:06:13 <TallTed> is stuck in previous meeting running over...
15:06:13 <TallTed> s/183https/183 -> https/
15:06:22 <bigbluehat> ... both should be easy
15:06:23 <TallTed> s/184https/184 -> https
15:06:29 <ottomorac> Subtopic: Make https binding mandatory #182
15:06:33 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/04-did-minutes.html TallTed
15:06:39 <ottomorac> https://github.com/w3c/did-resolution/pull/182
15:06:47 <bigbluehat> ottomorac: on this one we have a couple of questions
15:07:03 <bigbluehat> ... we have a requirement to implement some HTTPS binding
15:07:03 <bigbluehat> ... at minimum
15:07:03 <bigbluehat> ... but there are some questions
15:07:09 <ottomorac> Question  1- Is it a requirement on DID Methods or on DID resolvers?
15:07:09 <ottomorac> Question 2 - How do we implement the concept of the 2 conformance classes (libraries versus deployed did resolvers)
15:07:22 <manu> q+
15:07:37 <bigbluehat> ottomorac: I have heard that the DID Resolution spec can only require things of the resolvers
15:07:53 <bigbluehat> ... but as you can see in the conversation, others feel this could be a requirement on the methods
15:08:06 <bigbluehat> ... Question 2 is how do we deal with 2 conformance classes
15:08:10 <bigbluehat> ... I haven't seen that often
15:08:21 <bigbluehat> ... Wip did point me to specs where that has been done in the past
15:08:26 <ottomorac> ack manu
15:08:30 <bigbluehat> ... but I would appreciate some guidance
15:08:36 <bigbluehat> manu: for the 1st question
15:08:47 <bigbluehat> ... I think it's firmly a DID Resolver requirement
15:08:57 <bigbluehat> ... for DID Method requirements, it would have to be in DID Core
15:09:08 <smccown> smccown has joined #did
15:09:10 <bigbluehat> ... we could try to do that in DID Resolution, but it would likely get missed
15:09:22 <smccown> present+
15:09:22 <bigbluehat> ... and it feels strange to force that on DID Methods
15:09:25 <markus_sabadello> present+
15:09:26 <markus_sabadello> q+
15:09:26 <ivan> +1 to manu on method requirements should not be here
15:09:32 <bigbluehat> ... I haven't read the conversation, though, but would love to hear more
15:09:44 <bigbluehat> ... it feels like a DID Resolver requirement
15:10:00 <bigbluehat> ... for Question 2: can we do 2 conformance classes, yes, we can
15:10:07 <bigbluehat> ... this happens fairly often
15:10:23 <bigbluehat> ... especially between document conformance and library conformance
15:10:37 <bigbluehat> ... I think it's fine if we have 2 conformance classes in this case
15:10:46 <bigbluehat> ... really, this may be around do we require HTTP binding
15:10:47 <JoeAndrieu> q+ to suggest its a DID method requirement conceptually, but we can't fix that under this charter
15:10:54 <bigbluehat> ... so, the 2 classes may be about that?
15:11:10 <bigbluehat> ... so maybe we say DID resolving libraries vs. DID resolving services
15:11:22 <bigbluehat> ... doesn't have to be that language, but services would be the ones that have to support HTTP
15:11:43 <bigbluehat> ... however, libraries could be all kinds of things
15:11:51 <bigbluehat> ... so we may need to use more general language
15:12:02 <bigbluehat> ... and then we could use service to imply HTTP protocol support
15:12:05 <ottomorac> ack markus_sabadello
15:12:16 <bigbluehat> markus_sabadello: I think we're mostly aligned
15:12:29 <bigbluehat> ... just a matter of language, probably
15:12:50 <bigbluehat> ... I think the current sentence isn't very clear
15:13:04 <TallTed> present+
15:13:10 <bigbluehat> ... I interpreted it to read that if you did not have an HTTP binding you were not a conformant DID resolver
15:13:20 <bigbluehat> ... but as Manu points out, libraries may not support HTTP/S
15:13:30 <bigbluehat> ... and in the current language, that library would not be conformant
15:13:57 <bigbluehat> ... what Manu just called libraries and services are currently local and remote resolvers
15:14:17 <bigbluehat> ... so maybe with the current language we assign the HTTP binding to the remote resolvers only
15:14:22 <bigbluehat> ... but there's variation...
15:14:30 <bigbluehat> ... so I was a bit unsure of how to resolve it
15:14:56 <bigbluehat> ... and then I wondered if each method would then need to have at least one remote resolver that supports HTTP
15:15:10 <bigbluehat> ottomorac: this has been discussed before
15:15:12 <ottomorac> q?
15:15:34 <bigbluehat> markus_sabadello: yes. especially whether or not we require HTTPS binding on methods
15:15:52 <bigbluehat> ottomorac: so, there is an additional question if this becomes a requirement within DID Core
15:15:59 <ottomorac> ack JoeAndrieu
15:15:59 <Zakim> JoeAndrieu, you wanted to suggest its a DID method requirement conceptually, but we can't fix that under this charter
15:16:00 <bigbluehat> ... so the connection to DID Methods becomes clearer
15:16:21 <bigbluehat> JoeAndrieu: conceptually, I do think this is a DID Method requirement
15:16:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/04-did-minutes.html TallTed
15:16:59 <bigbluehat> ... I agree with markus_sabadello that requiring that a did:key resolver require HTTP access seems wonky
15:17:04 <bigbluehat> ... so I feel like the 2 conformance classes feels good
15:17:13 <bigbluehat> ... I do hesitate to call it local
15:17:26 <bigbluehat> ... but perhaps we can define it without defining it
15:17:42 <bigbluehat> ... by focusing the HTTP requirement on the "remote resolver" only
15:18:16 <bigbluehat> JoeAndrieu: if we do this right, we won't be accidently requiring HTTP access to DLLs or similar
15:18:30 <manu> +1 to what Joe said.
15:18:42 <bigbluehat> +1 agreed
15:18:53 <bigbluehat> ottomorac: I'll resolve this using local and remote resolver language
15:19:09 <bigbluehat> ... not sure if we need to define conformance classes here, but I'll handle that offline
15:19:14 <ottomorac> Topic: HTTP POST method binding #161
15:19:26 <bigbluehat> ottomorac: moving on to the next topic which is related in some sense.
15:19:27 <ottomorac> https://github.com/w3c/did-resolution/issues/161
15:19:33 <ottomorac> Currently, DID Resolution is specified with GET only. Many suggested a wording of &ldquo;"you MUST implement either POST or GET.", however that would impact the testing suite.
15:19:58 <bigbluehat> ... so far we have said POST or GET
15:20:04 <manu> q+
15:20:08 <bigbluehat> ... but Wip raised some complexity concerns around the test suite
15:20:08 <ottomorac> ack manu
15:20:27 <bigbluehat> manu: I thought where we got to was mandating GET
15:20:32 <bigbluehat> ... and you MAY implement POST
15:20:39 <bigbluehat> ... which would be largely for corner cases
15:21:05 <markus_sabadello> q+
15:21:12 <bigbluehat> ... so for 90%+ of cases GET is sufficient and we think for the remaining use cases POST can be used
15:21:12 <ottomorac> ack markus_sabadello
15:21:22 <bigbluehat> markus_sabadello: I missed that previous call
15:21:28 <bigbluehat> ... but that approach sounds right
15:21:33 <ottomorac> q?
15:22:30 <bigbluehat> ottomorac: who wants to handle this PR?
15:22:38 <bigbluehat> ... k...I'll take it
15:22:48 <bigbluehat> ... it seems innocent enought
15:22:54 <bigbluehat> s/enought/enough
15:23:07 <ottomorac> Topic: Define how DID Methods can specify paths and their dereferencing rules #156
15:23:15 <ottomorac> https://github.com/w3c/did-resolution/issues/156
15:23:21 <ottomorac> We discussed scheduling a Special topic call for issue #156:Define how DID Methods can specify paths and their dereferencing rules. Potential options includeL 24-Sept or 3-Oct. Thoughts from Joe and Manu?
15:23:45 <bigbluehat> ottomorac: I wanted to mainly get thoughts from JoeAndrieu and manu
15:23:53 <manu> q+
15:23:58 <ottomorac> ack manu
15:24:09 <bigbluehat> manu: either of those dates works just fine
15:24:48 <bigbluehat> JoeAndrieu: <finds problems with day/date alignment>
15:25:26 <JennieM> JennieM has joined #did
15:25:32 <JennieM> present+
15:25:33 <bigbluehat> JoeAndrieu: any of these can be made to work
15:25:44 <bigbluehat> ottomorac: let's go with September 24th then
15:25:48 <bigbluehat> ... sooner is better
15:26:05 <ottomorac> Topic: Create syntactic sugar for relativeRef feature #181
15:26:11 <ottomorac> https://github.com/w3c/did-resolution/issues/181
15:26:17 <ottomorac> Suggestion from Manu on how we can remove the usage of relativeRef and introduce a change in the syntax so that these relative references can be embedded more directly into in the did URL.
15:26:33 <ottomorac> Moving from things: like did:example:123?service=agent&relativeRef=/images/123.png
15:26:39 <ottomorac> To: did:example:123:/images/123.png
15:26:48 <ottomorac> Notice the   :/
15:27:00 <ottomorac> There is then a discussion between Dave Longley and Manu on the matter.
15:27:11 <JoeAndrieu> q+
15:27:18 <ottomorac> ack JoeAndriue
15:27:26 <ottomorac> ack JoeAndrieu
15:27:29 <bigbluehat> JoeAndrieu: this really ends up being part of the special topic call
15:27:33 <markus_sabadello> q+
15:27:45 <ottomorac> ack markus_sabadello
15:27:45 <bigbluehat> ottomorac: so just bundle it into the call on the 24th
15:27:47 <bigbluehat> JoeAndrieu: yes.
15:28:12 <manu> q+
15:28:23 <bigbluehat> markus_sabadello: I think this looks nice
15:28:30 <bigbluehat> ... but is this conformant with the ABNF
15:29:06 <bigbluehat> ... I think `service` and `relativeRef`, though, would still not go away
15:29:14 <bigbluehat> ... and get combined with other things
15:29:18 <ottomorac> ack manu
15:29:25 <bigbluehat> ... so I think this would be in addition too, not a replacement, correct?
15:29:46 <bigbluehat> manu: yes, this would be in addition
15:29:54 <PDL-ASU> PDL-ASU has joined #did
15:30:03 <JoeAndrieu> q+ to say this would break some current approaches
15:30:04 <bigbluehat> ... the way we do paths now is with colons which feels weird to many people
15:30:23 <bigbluehat> ... it may not be compliant
15:30:55 <bigbluehat> ... we're trying to solve one of the long standing issues we've had is doing path stuff with DIDs is really awkward
15:31:18 <bigbluehat> ... this is really just syntactic sugar for `relativeRef`
15:31:45 <bigbluehat> ... we'll have to think of a way to make this work if it does have issues with the current spec
15:31:51 <bigbluehat> ... there are ways we could handle it
15:32:03 <ottomorac> ack JoeAndrieu
15:32:03 <Zakim> JoeAndrieu, you wanted to say this would break some current approaches
15:32:08 <bigbluehat> ... but what I hope we end up with a way to do nice looking path stuff that doesn't break compatibility with other systems
15:32:21 <bigbluehat> JoeAndrieu: unfortunately, this does break current syntax
15:32:22 <manu> q+
15:32:32 <bigbluehat> ... did:cosmos for one would likely choke on this
15:32:46 <bigbluehat> ... I think the syntax sugar heads us the wrong way
15:32:55 <dmitriz> q+
15:32:55 <ottomorac> ack manu
15:32:56 <bigbluehat> ... because we loose out on the need for it to be URL encoded
15:33:06 <bigbluehat> manu: I don't think it breaks the use of the colon
15:33:15 <bigbluehat> ... the intent is not to break that specifically
15:33:22 <bigbluehat> ... for URL encoding, we'll have to look at that more
15:33:38 <markus_sabadello> q+
15:33:40 <bigbluehat> ... did:cosmos could say it doesn't support this syntactic sugar
15:33:43 <ottomorac> ack dimitriz
15:33:56 <ottomorac> ack dmitriz
15:34:08 <bigbluehat> dmitriz: I agree with manu and I think the syntactic sugar is extremely important
15:34:19 <bigbluehat> ... we have lots of need for relative references for many use cases
15:34:35 <bigbluehat> ... and `relativeRef` as the only option makes for very ugly URLs
15:34:39 <ottomorac> ack markus_sabadello
15:34:44 <bigbluehat> ... and if we don't address it people will roll their own solutions
15:34:49 <bigbluehat> ... so we might as well fix it
15:35:04 <bigbluehat> markus_sabadello: I'm not sure about allowing DID Methods to override this
15:35:17 <dmitriz> q+
15:35:18 <bigbluehat> ... these things do not have to be fully supported by all DID Methods
15:35:39 <bigbluehat> ... and the services don't care how you get the DID document
15:35:47 <ottomorac> ack dmitriz
15:35:53 <bigbluehat> ... and I worry about making this syntactic sugar method dependent
15:36:03 <bigbluehat> dmitriz: big +1. I think that's what at issue here
15:36:17 <bigbluehat> ... how do we keep each DID Method from solving for `relativeRef` their own way
15:36:38 <bigbluehat> ... one potential option is to define a service endpoint that defines the default relative ref service ID
15:36:41 <manu> q+
15:36:44 <bigbluehat> ... so, a 404 service of sorts
15:36:45 <ottomorac> ack manu
15:37:11 <bigbluehat> manu: dmitriz I interpreted what you said in two different ways
15:37:38 <bigbluehat> ... my concern if we don't make it optional is that we'll get formal objections
15:37:46 <bigbluehat> ... that's the only reason I'm proposing it be optional
15:37:55 <bigbluehat> ... but I expect many would opt in
15:38:11 <bigbluehat> ... but others may not because they chose a different path before this was introduced
15:38:24 <bigbluehat> ... I don't want to make it a requirement and then cause problems for them
15:38:28 <dmitriz> q+
15:38:38 <ottomorac> ack dmitriz
15:38:47 <bigbluehat> ... and we don't want to make this painful for various methods if we can avoid it
15:39:10 <bigbluehat> dmitriz: this does get revisited by several did methods
15:39:15 <bigbluehat> ... we need relative references
15:39:26 <bigbluehat> ... the DID Core syntax is too unwieldy
15:39:37 <bigbluehat> ... so, we need to find a did method where this is better
15:39:42 <bigbluehat> ... or create our own did method
15:39:56 <bigbluehat> ... and it would be better to have this solved in someway at did core
15:39:57 <dmitriz> did:example:123?service=agent&relativeRef=/images/123.png
15:40:31 <dmitriz> serviceEndpoints: [ { type: "default relativeRef service", value: agent } ]
15:40:49 <manu> oh, right, excellent, that makes sense to me.
15:40:50 <bigbluehat> ... these are some approaches
15:41:00 <manu> q+
15:41:05 <Wip> q+
15:41:05 <ottomorac> ack manu
15:41:15 <bigbluehat> manu: I think that's an excellent point dmitriz
15:41:34 <bigbluehat> ... that would also potentially address JoeAndrieu's concern about how did:cosmos does it now
15:41:50 <bigbluehat> ... and looking for that service endpoint would be a way to know if/when it's available
15:42:10 <bigbluehat> ... and situations like cosmos's would be more manageable through this expression
15:42:37 <bigbluehat> ... and if they ever wanted to do this, they'd have a mechanism that doesn't break backwards compatibility
15:42:52 <bigbluehat> ... another thing dlongley brought up was about static vs. dynamic references
15:43:11 <bigbluehat> ... imagine if a service is constantly under attack and they're having to shift those around to stay up
15:43:36 <bigbluehat> ... so, static resolution gives you a static URL and you dereference it staticly
15:43:50 <bigbluehat> ... and a dynamic resolution would provide a protocol that would eventually give you a path
15:43:50 <ottomorac> ack Wip
15:44:12 <bigbluehat> Wip: I think this is a great discussion, but I think we should move on and leave the rest for the special topic call
15:44:24 <bigbluehat> ... the chairs also feel this is one of the last remaining things to address in the spec
15:44:36 <JoeAndrieu> q+ to say I think the colon mechanism is a non-starter from a charter standpoint
15:44:43 <ottomorac> ack JoeAndrieu
15:44:43 <Zakim> JoeAndrieu, you wanted to say I think the colon mechanism is a non-starter from a charter standpoint
15:44:45 <bigbluehat> ... so I'd like to pause now, address it more on the 24th, and then make more time at TPAC
15:45:11 <bigbluehat> JoeAndrieu: delaying until the special topic call makes sens
15:45:13 <manu> q+ to say I don't agree :P
15:45:19 <ottomorac> ack manu
15:45:19 <Zakim> manu, you wanted to say I don't agree :P
15:45:26 <bigbluehat> ... if we go with the :/ approach, we'd have to change the ABNF
15:45:39 <bigbluehat> manu: that's the bit I was saying about language lawyering our way around it
15:45:56 <bigbluehat> ... it's not a DID and it's not a DID URL...it's a thing that gets translated into a DID
15:46:09 <bigbluehat> ... ideally, we don't have to...but that is an option
15:46:15 <bigbluehat> ... we could use any other separator
15:46:21 <bigbluehat> ... but this might be one of the features of this
15:46:34 <bigbluehat> ... since it is not valid syntax, then no one could have picked this
15:46:52 <bigbluehat> ... and so we know it won't break other things
15:47:04 <bigbluehat> JoeAndrieu: no, this change would break existing DIDs once this is introduced
15:47:13 <ottomorac> Topic: Model accept as the HTTP accept header#116
15:47:14 <bigbluehat> manu: so, we want to avoid that, so lets keep discussing
15:47:27 <ottomorac> https://github.com/w3c/did-resolution/issues/116
15:47:33 <ottomorac> There was agreement to model it after the HTTP Accept Header, there is change required in the DID resolution algorithm. We need someone to volunteer to create the PR.
15:47:56 <bigbluehat> ottomorac: looking for a volunteer for this PR
15:48:26 <brent> brent has joined #did
15:48:37 <pchampin> RRSAgent, make minutes
15:48:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/04-did-minutes.html pchampin
15:48:44 <bigbluehat> markus_sabadello: I can take this one
15:48:55 <ottomorac> Topic: Address incompatible entries in extensions registry #150
15:49:03 <ottomorac> https://github.com/w3c/did-resolution/issues/150
15:49:13 <ottomorac> We had some prior discussion of how to address this between Joe and Manu. Will discussed maybe adding an issue on the DID Extensions registry.
15:49:28 <Wip> q+
15:49:30 <JoeAndrieu> q+
15:49:32 <ottomorac> ack Wip
15:49:58 <ottomorac> ack JoeAndrieu
15:50:06 <markus_sabadello> markus_sabadello has joined #did
15:50:09 <markus_sabadello> q+
15:50:14 <bigbluehat> Wip: we do need manu for that, and can happen on the special topic call
15:50:15 <bigbluehat> JoeAndrieu: agreed
15:50:21 <ottomorac> ack markus_sabadello
15:50:31 <bigbluehat> ... all these options need to coalesce
15:50:38 <bigbluehat> markus_sabadello: agreed. this can be in the special topic call
15:50:53 <pchampin> s/header#116/header w3c/did-resolution#116
15:51:00 <bigbluehat> ... in my mind, the examples that are here are quite different than the syntactic sugar scenarios
15:51:14 <bigbluehat> ... and what we have here is completely did method dependent
15:51:15 <pchampin> s/feature #181/feature w3c/did-resolution#181
15:51:44 <bigbluehat> ... the differences can be discussed on the special topic call
15:51:47 <pchampin> s/rules #156/rules w3c/did-resolution#156
15:51:59 <bigbluehat> ottomorac: would it make sense to add the folks from did:cheqd to the special topic call?
15:52:02 <pchampin> present+ dmitriz
15:52:05 <bigbluehat> markus_sabadello: yes. I will do that
15:52:12 <bigbluehat> ... they were some of the first to explore that
15:52:30 <bigbluehat> JoeAndrieu: just to clarify, we were in the registry before them ;)
15:52:40 <pchampin> s/binding #161/binding w3c/did-resolution#161
15:52:41 <bigbluehat> ... but it would be good to get someone from there to join the call
15:52:55 <bigbluehat> ottomorac: anyone else we need to add?
15:53:04 <bigbluehat> JoeAndrieu: yes. I will reach out to others
15:53:19 <bigbluehat> ottomorac: 10 Eastern on September 24th
15:53:37 <pchampin> RRSAgent, make minutes
15:53:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/04-did-minutes.html pchampin
15:53:44 <bigbluehat> ottomorac: any other pressing issues?
15:53:51 <bigbluehat> JoeAndrieu: yes. maybe pchampin can help us clarify
15:53:53 <ottomorac> Topic: Other topics
15:54:09 <bigbluehat> ... what do we do with non-members who would be good to have on this call?
15:54:57 <bigbluehat> ... special topic call significant contributions can only be made by members
15:55:08 <bigbluehat> ... could we invite them as an invited expert?
15:55:28 <bigbluehat> ottomorac: we did want to cap the number of invited experts at some point
15:55:43 <bigbluehat> Wip: we could do that, but we only really need him for that one call
15:55:51 <bigbluehat> ivan: you can time limit the invitation
15:55:54 <bigbluehat> ... we don't usually do that
15:56:02 <bigbluehat> ... but we could say it's only for 3 months, for example
15:56:25 <bigbluehat> JoeAndrieu: I'll reach out. If he can't join us, we can defer that discussion
15:56:36 <bigbluehat> ... if he can make it, maybe it's worth the effort to invite him
15:56:39 <bigbluehat> ottomorac: k. that's it for today
15:56:42 <bigbluehat> ... thanks everyone!
16:01:55 <pchampin> RRSAgent, make minutes
16:01:56 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/04-did-minutes.html pchampin
16:02:16 <pchampin> m2gbot, link issues with transcript
16:02:17 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/183#issuecomment-3254418516
16:02:18 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/182#issuecomment-3254418562
16:02:19 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/161#issuecomment-3254418624
16:02:20 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/156#issuecomment-3254418678
16:02:20 <m2gbot> comment already there: https://github.com/w3c/did-resolution/issues/156#issuecomment-3254418678
16:02:22 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/181#issuecomment-3254418813
16:02:22 <m2gbot> comment already there: https://github.com/w3c/did-resolution/issues/181#issuecomment-3254418813
16:02:24 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/116#issuecomment-3254418936
16:02:25 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/150#issuecomment-3254418999
16:02:47 <ottomorac> hmm
16:02:50 <ottomorac> " comment already there"?
16:03:43 <ottomorac> at any rate it seems that it did work
17:58:59 <brent> brent has joined #did
18:02:02 <Zakim> Zakim has left #did
19:09:04 <brent> brent has joined #did
19:12:27 <ottomorac> rrsagent, please excuse us
19:12:27 <RRSAgent> I see no action items