13:54:31 <RRSAgent> RRSAgent has joined #lws
13:54:36 <RRSAgent> logging to https://www.w3.org/2025/06/16-lws-irc
13:54:36 <Zakim> RRSAgent, make logs Public
13:54:37 <Zakim> please title this meeting ("meeting: ..."), laurens
13:54:41 <laurens> Meeting: Linked Web Storage Meeting 16 June, 2025
13:54:50 <laurens> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250616T100000/
13:54:50 <agendabot> clear agenda
13:54:50 <agendabot> agenda+ Introductions and announcements
13:54:50 <agendabot> agenda+ Relationship between Protocol and UC&R document
13:54:50 <agendabot> agenda+ Discussion: Resource identifiers
13:57:13 <acoburn> acoburn has joined #lws
13:58:29 <TallTed> RRSAgent, draft minutes
13:58:31 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/16-lws-minutes.html TallTed
13:59:38 <jeswr> jeswr has joined #lws
13:59:45 <jeswr> present+
13:59:49 <acoburn> present+
13:59:50 <laurens> present+
14:00:08 <TallTed> previous meeting: https://www.w3.org/2025/06/09-lws-minutes.html
14:00:08 <TallTed> next meeting: https://www.w3.org/2025/06/23-lws-minutes.html
14:00:12 <uvdsl> uvdsl has joined #lws
14:00:36 <gibsonf1> gibsonf1 has joined #lws
14:00:48 <TallTed> present+
14:00:54 <cpn> cpn has joined #lws
14:01:00 <pchampin> present+
14:01:02 <cpn> present+
14:01:10 <RazaN> RazaN has joined #lws
14:01:11 <uvdsl> present+
14:01:26 <gibsonf1> present+
14:01:49 <acoburn> scribenick: acoburn
14:01:52 <laurens> chair: laurens
14:01:54 <RazaN> present+
14:02:30 <gibsonf1> I can attempt to scribe
14:02:38 <bendm> bendm has joined #lws
14:02:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/16-lws-minutes.html TallTed
14:03:08 <bendm> present+ bendm
14:03:12 <acoburn> zakim, open agendum 1
14:03:12 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
14:03:30 <ryey> ryey has joined #lws
14:03:35 <ryey> present+
14:04:13 <Monsecom> Monsecom has joined #lws
14:04:14 <jackson> jackson has joined #lws
14:04:16 <acoburn> laurens: no announcements
14:04:23 <acoburn> zakim, open agendum 2
14:04:23 <Zakim> agendum 2 -- Relationship between Protocol and UC&R document -- taken up [from agendabot]
14:04:29 <Monsecom> present+
14:04:47 <acoburn> laurens: jeswr and ebremer are starting work on protocol deliverable
14:05:00 <acoburn> ... ucr WG note work is ongoing
14:05:11 <acoburn> ... both deliverables need to keep up momentum
14:05:35 <dmitriz> dmitriz has joined #lws
14:05:37 <acoburn> ... ucr is essential for distilling requirements
14:05:48 <acoburn> ... also allows us room for prioritization and scope discussions
14:06:08 <acoburn> ... protocol doc has interplay in other direction in showing what the protocol may look like
14:06:14 <acoburn> ... at this stage, both are living documents
14:06:57 <Beau> Beau has joined #lws
14:07:01 <Beau> present+
14:07:20 <laurens> acoburn: As we begin discussing the details of the protocol, we'll have to have scoping discussions and prioritization conversations which should be informed by the UC&R document
14:07:41 <laurens> ... in an ideal scenario the UC&R would be complete, however the timeline doesn't afford us that flexibility
14:07:54 <laurens> ... so we'll have to move both forward, realizing that is not ideal.
14:08:02 <uvdsl> q+ to say UCs have not yet been reviewed wrt to scope of the protocol according to the charter (as far as I see)
14:08:23 <laurens> ack uvdsl
14:08:23 <Zakim> uvdsl, you wanted to say UCs have not yet been reviewed wrt to scope of the protocol according to the charter (as far as I see)
14:08:55 <acoburn> uvdsl: yes, we should discuss use cases, emphasizing that we haven't yet seen which are in scope
14:09:04 <acoburn> laurens: the scoping discussion has not yet been had
14:09:36 <pchampin> q+
14:09:38 <acoburn> ... the scope discussion will be easier once we have a clearer sense of the overall ucr document
14:09:44 <laurens> ack pchampin
14:10:02 <eBremer> eBremer has joined #lws
14:10:04 <acoburn> pchampin: to complement, the coverage/refinement of UCRs is one criteria
14:10:07 <eBremer> present+
14:10:26 <acoburn> ... the other requirement is the charte
14:10:29 <laurens> q?
14:10:31 <acoburn> s/charte/charter
14:11:25 <acoburn> laurens: is the publication process moving forward?
14:11:56 <acoburn> pchampin: hadrian had a change of affiliation, and we cannot publish right now, will be sorted this week
14:12:05 <acoburn> zakim, open agendum 3
14:12:05 <Zakim> agendum 3 -- Discussion: Resource identifiers -- taken up [from agendabot]
14:12:18 <uvdsl> https://github.com/w3c/lws-protocol/issues/28
14:12:19 <gb> https://github.com/w3c/lws-protocol/issues/28 -> Issue 28 Resource Identification (by uvdsl)
14:12:38 <acoburn> laurens: there has been some discussion related in the protocol repository
14:12:54 <acoburn> ... the editors would like to begin drafting some text
14:13:31 <acoburn> ... one of the first and foundational item is that identifiers should be globally unique
14:13:50 <acoburn> ... iri vs uri can be discussed later on
14:14:00 <uvdsl> q+
14:14:00 <gibsonf1> +1
14:14:01 <laurens> q?
14:14:05 <acoburn> ... seems we are mostly in consensus, but would like to hear thoughts
14:14:08 <laurens> ack uvdsl
14:14:24 <acoburn> uvdsl: does the group want uri/iri ?
14:14:45 <acoburn> laurens: I don't want to start there, would like to start with whether the identifiers are globally unique
14:14:50 <dmitriz> what do you mean by 'atomic'?
14:14:53 <gibsonf1> q+ to say in addition to global unique, reachable via webn
14:15:20 <acoburn> laurens: by atomic, I mean that it can be completely identified in a single string
14:15:27 <uvdsl> q+
14:15:32 <laurens> ack gibsonf
14:15:32 <Zakim> gibsonf, you wanted to say in addition to global unique, reachable via webn
14:15:35 <acoburn> ... unlike in SOAP where multiple elements (tuple) is needed
14:15:51 <acoburn> gibsonf: agree about globally unique, also reachable
14:16:10 <acoburn> ericP: is that the distinction between locator and identifiers?
14:16:23 <laurens> q?
14:16:25 <laurens> ack uvdsl
14:16:59 <acoburn> uvdsl: for me I agree with gibsonf, that they are specifically using HTTP URIs (from charter docs)
14:17:21 <jackson> q+
14:17:24 <acoburn> ... in SOAP, there is a tuple of identifier and operation
14:17:27 <TallTed> q+
14:17:28 <laurens> ack jackson
14:17:41 <acoburn> jackson: would like to push back on HTTP uris
14:18:09 <acoburn> ... the current Solid CG Report requires HTTP URIs and it is hard to be compatible with DID
14:18:17 <acoburn> ... limiting to HTTP URIs is very limiting
14:18:34 <dmitriz> what's the motivation for limiting the protocols, out of curiosity?
14:18:44 <uvdsl> q+ to point to the bindings decision https://github.com/w3c/lws-protocol/issues/24
14:18:45 <gb> https://github.com/w3c/lws-protocol/issues/24 -> Issue 24 Reasons for separate rest bindings (by jeswr)
14:18:47 <acoburn> ... perhaps a provision in the specification to allow for certain protocols
14:18:57 <laurens> ack TallTed
14:19:22 <acoburn> tallted: pretty much in favor of the first part (global uniqueness)
14:19:40 <acoburn> ... I question atomicity: there may be fragment identifiers
14:20:02 <gibsonf1> q+ to say are we limiting representations to documents (re TallTed)
14:20:03 <acoburn> ... relatedly, one goal of LWS is that a user can choose to move between providers
14:20:27 <acoburn> ... if we limit to HTTP URIs, that requires additional infrastructure to not break links
14:20:56 <acoburn> ... some providers allow vanity domains, but not all, esp financial institutions
14:20:57 <laurens> ack uvdsl
14:20:57 <Zakim> uvdsl, you wanted to point to the bindings decision https://github.com/w3c/lws-protocol/issues/24
14:21:18 <acoburn> uvdsl: this comes back to issue #24 related to bindings
14:21:19 <gb> https://github.com/w3c/lws-protocol/issues/24 -> Issue 24 Reasons for separate rest bindings (by jeswr)
14:21:37 <acoburn> ... i.e. whether to have binding or to tightly couple with HTTP
14:22:12 <acoburn> ... limiting to HTTP URIs is restricting, it makes sense to limit to the transfer protocol. That doesn't limit to HTTP URIs
14:22:23 <dmitriz> q+ to ask _why_ we're limiting protocols
14:22:27 <acoburn> ... there are DID methods that allow for HTTP transfer protocol
14:22:35 <laurens> ack gibsonf
14:22:35 <Zakim> gibsonf, you wanted to say are we limiting representations to documents (re TallTed)
14:22:39 <TallTed> q+ to mention DID "universal resolver"
14:22:55 <acoburn> gibsonf: related to the document, we are not limiting a resource to a document
14:23:05 <acoburn> ... I hope that is not the only thing to expect as a representation
14:23:07 <laurens> ack dmitriz
14:23:07 <Zakim> dmitriz, you wanted to ask _why_ we're limiting protocols
14:23:17 <acoburn> dmitriz: why are we limiting URL protocols?
14:23:22 <uvdsl> q+ to counterask
14:23:22 <jackson> q+
14:23:23 <acoburn> ... what does that buy us
14:23:28 <laurens> ack TallTed
14:23:28 <Zakim> TallTed, you wanted to mention DID "universal resolver"
14:23:29 <acoburn> ... what problem does it solve?
14:23:47 <acoburn> tallted: there was also a concern raised about resolving DID methods for arbitrary methods
14:24:05 <acoburn> ... the expectations from the DID WG that there will be libraries with global resolvers
14:24:31 <acoburn> ... i.e. "resolve this did" and the client receives whatever the identifier references
14:24:35 <laurens> q?
14:24:38 <laurens> ack uvdsl
14:24:38 <Zakim> uvdsl, you wanted to counterask
14:25:00 <acoburn> uvdsl: my perspective is that the specification should give implementers clear guidance
14:25:04 <dmitriz> q+
14:25:07 <laurens> ack jackson
14:25:09 <gibsonf1> +1 to uvdsl
14:25:12 <acoburn> ... and without that guidance, we defeat the purpose of the spec
14:25:14 <ryey> q+
14:25:37 <dmitriz> that doesn't make any sense. do we also want to constrain the _packets_ to TCP only?
14:25:41 <acoburn> jackson: as an implementer, I'd want to make it easy, but I'd want a specific group to implement
14:25:57 <acoburn> laurens: we need to produce a test suite, and it needs to be testable
14:26:07 <acoburn> ... any restriction needs to serve a purpose
14:26:21 <acoburn> ... e.g. identifiers that are also locators
14:26:28 <laurens> ack dmitriz
14:26:30 <uvdsl> q+ counter-argument, flexibility should only be written into the spec if there are use cases aligned with the carter require it
14:26:30 <acoburn> ... I want a concrete requirement for that restriction
14:27:10 <acoburn> dmitriz: we are not going to constrain to TCP or how packets resovle over the wire
14:27:19 <laurens> q?
14:27:22 <pchampin> q+
14:27:26 <jackson> q+
14:27:26 <acoburn> ... we should say URLs and not specify the retrieval mechanism
14:27:30 <laurens> ack ryey
14:27:33 <TallTed> +1 this may be premature restriction
14:27:35 <uvdsl> q+ counter-argument, flexibility should only be written into the spec if there are use cases
14:27:43 <laurens> q?
14:27:47 <acoburn> ryey: I second dmitriz's perspective
14:27:49 <uvdsl> q+ to counter-argument flexibility should only be written into the spec if there are use cases
14:27:54 <acoburn> ... specifying URIs would be fine
14:28:26 <acoburn> ... for the issue of portability, there are ways to approach this with relative URLs
14:28:35 <acoburn> ... or a special header for where to resolve
14:28:52 <acoburn> ... in the end there isn't a real issue for how the resource is identified
14:28:55 <laurens> ack pchampin
14:29:28 <acoburn> pchampin: I sypathize with dmitri's argument, that we want to rely on existing things that are specified elsewhere
14:29:35 <acoburn> ... however, URIs are very abstract
14:29:49 <acoburn> ... and we may want to characterize the properties of the URIs that we use
14:29:53 <acoburn> ... e.g. resolvability
14:30:08 <laurens> q?
14:30:12 <laurens> ack jackson
14:30:28 <acoburn> jackson: I don't think we should restrict only on HTTP
14:31:04 <acoburn> ... if I am a client library, and someone has included a link to some location with a weird protocol
14:31:35 <acoburn> ... e.g. if we say that we support 3 protocols and therefore all client libraries need to support all
14:31:48 <laurens> q?
14:31:51 <laurens> ack uvdsl
14:31:51 <Zakim> uvdsl, you wanted to counter-argument flexibility should only be written into the spec if there are use cases
14:31:56 <acoburn> ... spec should have a mechanism to say these are the required protocols and here's how to expand
14:32:14 <acoburn> uvdsl: I agree about restricting to a list, I don't like a registry because it is too open
14:32:36 <acoburn> ... I would push back on notion that we need to accommodate flexibility
14:32:54 <acoburn> ... flexibility should only be part of the spec based on use cases, as outlined by the charter
14:33:05 <acoburn> q+ to mention did and vc input documents
14:33:18 <acoburn> ... that will raise questions down the line
14:33:21 <laurens> ack acoburn
14:33:21 <Zakim> acoburn, you wanted to mention did and vc input documents
14:33:39 <dmitriz> text should be added to the spec only if it's solving a problem. restricting to http URLs is not solving any problem that was identified...
14:33:49 <laurens> acoburn: As I recall we have both the DID WG and VC WG and the documents they produce as inputs to our work
14:33:54 <laurens> ... that is part of the scope.
14:33:55 <uvdsl> q+ did group and vc group are only to be aligned with - not normative input
14:33:56 <uvdsl> q+ did group and vc group are only to be aligned with - not normative input
14:33:58 <laurens> q?
14:34:12 <laurens> q+
14:34:29 <acoburn> uvdsl: did and vc groups are to be aligned but they are not normatively listed as input documents
14:34:44 <acoburn> ... arguing to be careful about what we write into the spec
14:34:46 <pchampin> uvdsl, I agree that we must not aim at flexibility for the sake of it; but I do believe that the flexibility discussed here (esp. for portability) is backed by use-cases
14:35:09 <uvdsl> pchampin, sure! Looking forward to seeing these use cases :)
14:35:18 <acoburn> laurens: vc and did documents are w3c recommendations and should be included in our consideration
14:35:23 <laurens> q?
14:35:25 <ryey> q+
14:35:25 <acoburn> ... and some level of interop
14:35:30 <laurens> ack ryey
14:35:43 <dmitriz> the burden of proof should be on why add restrictions in the first place.
14:35:58 <acoburn> ryey: a few weeks ago, the DID resolver WG was being created. Is DID resolution already a thing?
14:36:08 <pchampin> q+ to respond to ryey
14:36:14 <laurens> ack pchampin
14:36:14 <Zakim> pchampin, you wanted to respond to ryey
14:36:15 <uvdsl> dmitriz, I disagree with that statement
14:36:31 <acoburn> pchampin: did resolution is not currently a recommendation
14:36:33 <laurens> ack laurens
14:36:41 <acoburn> ... it is a work item on the REC track
14:36:49 <acoburn> ... so eventually would be a REC
14:37:02 <dmitriz> q+
14:37:09 <acoburn> ryey: are there rules of thumb for working with other W3C draft documents?
14:37:22 <acoburn> laurens: we have discussed this related to input documents
14:37:39 <acoburn> pchampin: we cannot have normative dependencies on doc that are much less mature
14:37:46 <acoburn> ... we are allowed one level of difference
14:37:57 <acoburn> ... we are currently behind did resolution
14:38:03 <laurens> q?
14:38:07 <laurens> ack dmitriz
14:38:12 <acoburn> ... unless they have problems, we shouldn't have an issue there
14:38:30 <acoburn> dmitriz: each did method has a definition for how a did is resolved
14:38:42 <acoburn> ... still very strongly against restricting URI protocols
14:39:00 <acoburn> ... imagine restricting to only HTTP but then HTTPS comes
14:39:05 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/16-lws-minutes.html TallTed
14:39:18 <acoburn> ... one example: this exact question is a problem in the VC community
14:39:32 <acoburn> ... there is a spec for OpenID federation for issuer registries
14:40:00 <acoburn> ... that specs restricts to HTTPS, trying to exclude DIDs
14:40:41 <acoburn> ... all that ended up happening is that the VC group read the spec
14:40:52 <acoburn> ... and either had to ignore spec restriction or fork the spec
14:41:07 <acoburn> laurens: I want to second that
14:41:26 <acoburn> ... there are maintainability issues with too much restrictions without clear use cases
14:41:30 <uvdsl> q+
14:41:35 <laurens> ack uvdsl
14:41:59 <laurens> q+
14:42:10 <acoburn> uvdsl: for updating the scheme of the URI, why not open up a version 2?
14:42:22 <acoburn> ... the discussion in CG is very different
14:42:42 <acoburn> ... I don't think the arguments presented would convince the community group
14:42:49 <jackson> q+
14:43:17 <acoburn> laurens: this is a discussion that could be made broader, but this needs to be clarified in this WG
14:43:26 <acoburn> ... also reinstating a working group is not simple
14:43:39 <acoburn> q+ Note also that OpenID Federation is not W3C
14:43:41 <laurens> q?
14:43:45 <laurens> ack laurens
14:43:46 <laurens> ack jackson
14:43:58 <acoburn> q+ to note also that OpenID Federation is not W3C
14:44:10 <acoburn> jackson: I have an open mind, but I'd like more clarification
14:44:33 <acoburn> ... if we have a specification with open URIs that include links using a random URI scheme
14:44:58 <acoburn> ... and the technology encounters that, then a client library won't know how to resolve that
14:45:21 <dmitriz> q+
14:45:27 <acoburn> ... what should happen to client libraries
14:45:36 <laurens> ack dmitriz
14:45:44 <acoburn> dmitriz: the answer is always: "throw an error"
14:45:53 <uvdsl> so much for interoperability
14:46:05 <acoburn> ... i.e. what happens if you try to fetch a URL over HTTP and there is a network issue or server error
14:46:10 <acoburn> ... but the principle is the same
14:46:12 <laurens> q?
14:46:16 <laurens> ack acoburn
14:46:16 <Zakim> acoburn, you wanted to note also that OpenID Federation is not W3C
14:46:35 <laurens> acoburn: OpenID and W3C are different governance bodies
14:46:41 <jackson> q+
14:46:42 <uvdsl> q+
14:46:47 <laurens> ... when crossing boundaries this isn't as straightforward
14:46:51 <ericP> ericP has joined #lws
14:46:53 <laurens> ack jackson
14:46:57 <ericP> present+
14:47:25 <acoburn> jackson: re: "throw an error", if there is a network error, the error handling is already baked in
14:47:39 <acoburn> ... there should be a base level where every client library needs to implement
14:47:46 <ericP> q+ to describe requirements (MUST impelement) in terms of branding
14:47:57 <dmitriz> sure, "at least implement HTTP" seems reasonable as a requirement.
14:48:07 <acoburn> ... would your proposal be "at least implement these protocols"?
14:48:17 <laurens> q?
14:48:20 <acoburn> ... or that we shouldn't even mention http/did in the specification
14:48:30 <laurens> ack uvdsl
14:48:53 <acoburn> uvdsl: re "throw an error" flies in the face of the solid charter
14:49:04 <acoburn> ... this makes interoperability challenging
14:49:06 <dmitriz> @uvdsl -- part of our charter is to define error conditions.
14:49:06 <gb> https://github.com/uvdsl -> @uvdsl
14:49:24 <acoburn> ... you can have spec compliant systems that don't interoperate
14:49:28 <laurens> q?
14:49:32 <laurens> ack ericP
14:49:32 <Zakim> ericP, you wanted to describe requirements (MUST impelement) in terms of branding
14:49:33 <acoburn> ... I don't think this aligns with the goals of the charter
14:49:57 <acoburn> ericP: we should describe the optional and required protocols as "branding"
14:50:06 <uvdsl> sure, so you suggest prioritising error conditions over interoperability?
14:50:26 <acoburn> ... if someone goes to one place to get a server and elsewhere to get a client, there is a desire that they talk to each other
14:50:35 <dmitriz> I'm suggesting that restricting url protocols does not buy you interoperability. all that it buys you is -- either the spec gets forked, or implementers will just ignore it.
14:50:46 <acoburn> ... the "box" could be lws+did
14:51:31 <uvdsl> dmitriz, so you say that agreeing on a transport protocol does not induce interoperability? That is an interesting take.
14:51:32 <dmitriz> this is not hypothetical, either -- this JUST happened with open id federation.
14:51:32 <acoburn> ... if someone creates a resource with HTTP and then performs a GET over SPARQL, you want to be able to say that the resource is the same
14:51:38 <laurens> q?
14:51:54 <jackson> q+
14:51:58 <laurens> ack jackson
14:52:03 <dmitriz> @uvdsl - we're not talking about transport protocol though, notice. we're not talking about TCP or UDP. which is my point.
14:52:03 <gb> https://github.com/uvdsl -> @uvdsl
14:52:13 <dmitriz> we're talking about unnecessary URL protocol restriction.
14:52:23 <acoburn> jackson: that seems acceptable: a few requirements, but don't invalidate other implementations that use others
14:53:02 <uvdsl> Yeah, we were talking about HTTP. And agreeing on HTTP does not induce interoperability?
14:53:02 <acoburn> laurens: we need to be mindful of layering of future applications/domains on top of LWS
14:53:13 <laurens> q?
14:53:31 <acoburn> RRSAgent, draft minutes
14:53:33 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/16-lws-minutes.html acoburn
14:53:39 <uvdsl> You are right, HTTP is of course not transport.
14:53:55 <laurens> PROPOSAL: Protocol document to include HTTP resource identifiers despite not yet having been formalized as a requirement in the Use Cases & Requirements WG Note.
14:54:02 <acoburn> laurens: there was a discussion to use HTTP URIs in the protocol document
14:54:23 <ericP> +1
14:54:26 <eBremer> +1
14:54:27 <laurens> +1
14:54:27 <acoburn> +1
14:54:28 <TallTed> +1
14:54:28 <bendm> +1
14:54:30 <jeswr> +1
14:54:30 <gibsonf1> +1
14:54:30 <dmitriz> +1
14:54:34 <uvdsl> +1
14:54:39 <pchampin> +1
14:54:45 <RazaN> +1
14:54:50 <jackson> +1
14:54:51 <ryey> +1
14:55:09 <laurens> RESOLUTION: Protocol document to include HTTP resource identifiers despite not yet having been formalized as a requirement in the Use Cases & Requirements WG Note.
14:56:11 <uvdsl> https://github.com/w3c/lws-protocol/issues/28
14:56:12 <gb> https://github.com/w3c/lws-protocol/issues/28 -> Issue 28 Resource Identification (by uvdsl)
14:56:13 <acoburn> uvdsl: having arguments in writing and being able to discuss async would be appreciated
14:56:21 <pchampin> q+
14:56:32 <pchampin> q-
14:56:33 <acoburn> laurens: yes, we very much encourage that
14:57:09 <pchampin> uvdsl, I will add a pointer to the minutes of the discussions we just had in issue 28
14:57:35 <acoburn> hadrian: applied for IE status, began re-working some UCR docs
14:57:40 <uvdsl> Okay, thank you pchampin !
14:57:40 <laurens> q?
14:57:57 <acoburn> RRSAgent, draft minutes
14:57:59 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/16-lws-minutes.html acoburn
14:58:05 <Monsecom> Thanks!
14:58:06 <gibsonf1> +1
14:59:03 <m2gbot> m2gbot has joined #lws
14:59:28 <acoburn> present+ dmitriz
14:59:33 <acoburn> present+ hadrian
14:59:47 <acoburn> present+ jackson
14:59:57 <acoburn> present+ gibsonf
15:00:07 <acoburn> RRSAgent, draft minutes
15:00:09 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/16-lws-minutes.html acoburn
15:26:11 <acoburn> acoburn has left #lws