13:58:58 <RRSAgent> RRSAgent has joined #lws
13:59:03 <RRSAgent> logging to https://www.w3.org/2025/08/11-lws-irc
13:59:03 <Zakim> RRSAgent, make logs Public
13:59:04 <Zakim> please title this meeting ("meeting: ..."), pchampin
13:59:11 <pchampin> meeting: Linked Web Storage WG Meeting
13:59:17 <pchampin> previous meeting: https://www.w3.org/2025/08/04-lws-minutes.html
13:59:27 <gibsonf1> gibsonf1 has joined #lws
13:59:40 <pchampin> next meeting: https://www.w3.org/2025/08/18-lws-minutes.html
14:00:09 <eBremer> eBremer has joined #lws
14:00:20 <gibsonf1> present+
14:00:22 <TallTed> present+
14:00:28 <pchampin> present+
14:00:45 <eBremer> present+
14:00:54 <laurens> laurens has joined #lws
14:01:01 <pchampin> chair: laurens
14:01:10 <ryey> ryey has joined #lws
14:01:38 <pchampin> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250811T100000/#agenda
14:01:38 <agendabot> clear agenda
14:01:38 <agendabot> agenda+ Introductions and announcements
14:01:38 <agendabot> agenda+ Action Items
14:01:38 <agendabot> agenda+ Continued clarification of -> requirements https://w3c.github.io/lws-ucs/spec/#requirements (from -> Notifications and Eventing https://w3c.github.io/lws-ucs/spec/#dfn-notification-and-eventing )
14:01:40 <bartb> bartb has joined #lws
14:01:50 <bartb> present+
14:01:53 <pchampin> scribe+
14:02:31 <laurens> present+
14:02:31 <otherJackson> otherJackson has joined #lws
14:02:35 <pchampin> zakim, open item 1
14:02:35 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
14:02:37 <otherJackson> present+
14:02:50 <pchampin> laurens: I don't think we have any newcomer. Any announcement?
14:02:58 <bendm> bendm has joined #lws
14:03:19 <pchampin> ... Reminder that next week, the meeting will be chaired by jesse
14:03:28 <pchampin> zakim, open next item
14:03:28 <Zakim> agendum 1 was just opened, pchampin
14:03:35 <pchampin> zakim, close item 1
14:03:35 <Zakim> agendum 1, Introductions and announcements, closed
14:03:36 <Zakim> I see 2 items remaining on the agenda; the next one is
14:03:36 <Zakim> 2. Action Items [from agendabot]
14:03:38 <pchampin> zakim, open next item
14:03:38 <Zakim> agendum 2 -- Action Items -- taken up [from agendabot]
14:03:55 <pchampin> laurens: the only open action is assigned to Hadrian, who is not there.
14:03:59 <pchampin> ... Let's table this.
14:04:03 <pchampin> zakim, close item 2
14:04:03 <Zakim> agendum 2, Action Items, closed
14:04:05 <Zakim> I see 1 item remaining on the agenda:
14:04:05 <Zakim> 3. Continued clarification of -> requirements https://w3c.github.io/lws-ucs/spec/#requirements (from -> Notifications and Eventing
14:04:05 <Zakim> ... https://w3c.github.io/lws-ucs/spec/#dfn-notification-and-eventing ) [from agendabot]
14:04:07 <pchampin> zakim, open next item
14:04:07 <Zakim> agendum 3 -- Continued clarification of -> requirements https://w3c.github.io/lws-ucs/spec/#requirements (from -> Notifications and Eventing
14:04:09 <Zakim> ... https://w3c.github.io/lws-ucs/spec/#dfn-notification-and-eventing ) -- taken up [from agendabot]
14:04:30 <pchampin> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-notification-and-eventing Requirement: Notification and Eventing
14:04:42 <pchampin> laurens: this is related to the Solid Notification CG spec
14:04:58 <pchampin> ... it is about to notification between users, and between services.
14:05:14 <pchampin> ... It somewhat overlaps with Req 18 which we discussed last week.
14:05:26 <uvdsl> uvdsl has joined #lws
14:05:38 <pchampin> s/Req 18/Req 18 "Inter-user communication"
14:05:47 <pchampin> ... What do others think?
14:05:55 <gibsonf1> q+ to talk about inbox...
14:05:56 <pchampin> jesse: it does look like a duplicate.
14:06:02 <pchampin> ... There are two kinds of scenarios:
14:06:25 <pchampin> ... I want to subscribe to someone else's resource on their pod, this would be "notification and eventing"
14:06:46 <pchampin> ... The other is: I post something to my pod, then posts something to your inbox.
14:06:51 <pchampin> ... We should distinguish the two.
14:07:15 <pchampin> laurens: agreed; I can even see a 3rd one that may be a special case of the other: notification of change in ACL
14:07:44 <pchampin> q+
14:07:57 <pchampin> ... let's keep them separate, then, but "Inter-user communication" should be clarified
14:07:58 <pchampin> q-
14:08:07 <laurens> ack gibsonf
14:08:07 <Zakim> gibsonf, you wanted to talk about inbox...
14:08:10 <pchampin> jesse: we actually already have a proposal for renaming "Inter-user communication"
14:08:31 <uvdsl> uvdsl has joined #lws
14:08:34 <uvdsl> present+
14:08:49 <pchampin> gibsonf1: we discussed this last time; I believe that 18 is about the Inbox that we have now, while the other is about change notification.
14:08:59 <pchampin> ... I concur that we should keep them separated.
14:09:29 <pchampin> laurens: if we clarify 14 (Notification and Eventing), then we go a long way
14:10:17 <pchampin> ... The "Notification specification" aligns with 14.
14:10:33 <pchampin> ... The "Inbox specification" is not really described in the Solid CG spec, but would be more aligned to 18.
14:10:47 <pchampin> jesse: I would say "Subscribing to resource changes (notification)"
14:10:55 <otherJackson> +1
14:10:57 <laurens> +1
14:11:03 <uvdsl> 0
14:11:07 <pchampin> <pchampin> +1
14:11:10 <gibsonf1> +1 to also include acess permissions not subscribed to
14:11:11 <ryey> +1
14:11:18 <bendm> 0
14:11:25 <eBremer> +1
14:11:51 <bartb> 0
14:12:13 <jeswr> jeswr has joined #lws
14:12:15 <pchampin> laurens: I see support
14:12:31 <pchampin> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-data-versioning Requirement: Data Versioning
14:12:52 <pchampin> laurens: as far as I'm aware, Data Versioning is not part of any input docupent listed in our charter.
14:12:55 <TallTed> is it not covered by WebDAV?
14:13:12 <pchampin> ... I'm curious to hear about the use-cases that people have in mind.
14:13:27 <pchampin> ... TallTed: I'm not sure, it might indeed be covered by WebDAV.
14:13:29 <TallTed> s/docupent/document
14:13:43 <gibsonf1> q+ to talk about versioning
14:13:50 <ryey> q+ potentially CRDT, and/or collaborative editing. But not enforcing it
14:13:56 <pchampin> jesse: I suggest that at most in the LWS we have metadata for last-changed,
14:14:06 <ryey> q+ to discuss potentially CRDT, and/or collaborative editing. But not enforcing it
14:14:10 <laurens> q?
14:14:13 <pchampin> ... but we don't go into specifying how to retrieve previous versions.
14:14:14 <laurens> ack gibsonf
14:14:14 <Zakim> gibsonf, you wanted to talk about versioning
14:14:24 <pchampin> ... I see the value, but this is for a separate spec.
14:14:47 <pchampin> q+
14:14:56 <laurens> q?
14:15:02 <pchampin> gibsonf1: I agree with Jesse. This is valuable, but we would need to define the intricacies of how to retrieve previous versions.
14:15:03 <laurens> ack ryey
14:15:03 <Zakim> ryey, you wanted to discuss potentially CRDT, and/or collaborative editing. But not enforcing it
14:15:15 <pchampin> ryey: I agree with that as well.
14:15:33 <pchampin> ... CRDTs and the like would be a use-case for this kind of feature.
14:15:37 <otherJackson> q+
14:15:50 <uvdsl> Isn't there already versioning via memento (or something called similarly?) I recall some LDP implementation supporting something like that (I think it was Marmotta)
14:16:12 <pchampin> ... Some basice things should be there to avoid damaging the data in this context,
14:16:21 <laurens> q?
14:16:25 <pchampin> ... but it does not have to be a full-fledged versioning feature.
14:16:27 <laurens> ack pchampin
14:16:59 <laurens> pchampin: There is something called "Memento", as an HTTP extension to retrieve previous versions whenever supported.
14:17:14 <bartb> q+
14:17:22 <laurens> ... I generally agree that this is out-of-scope and should be a separate spec.
14:17:30 <eBremer> Memento --> https://www.rfc-editor.org/rfc/rfc7089.html
14:17:30 <laurens> ... we could hint at other specifications.
14:17:36 <laurens> q?
14:18:04 <ryey> q+ to say about metadata / aux file -- is it not in the requirements?
14:18:13 <pchampin> otherJackson: I would support saying "servers MAY support memento", not require it.
14:18:14 <laurens> ack otherJackson
14:18:59 <pchampin> ... it should be discoverable if the server supports it, to avoid application to duplicate work by deploying their own version management system.
14:19:04 <laurens> ack bartb
14:19:29 <pchampin> bartb: I think having something like a current version of latest version could be useful.
14:20:11 <laurens> q?
14:20:13 <pchampin> ... Example with shring your current address or body weight; you don't necessarily want to lose the previous versions.
14:20:15 <gibsonf1> q+ to ask - maybe its as simple as adding ?date=timestamp to a request url for a previous if it exists
14:20:25 <laurens> q?
14:20:28 <pchampin> present+ jesse
14:20:36 <pchampin> jesse: I would argue that there is a difference.
14:20:48 <pchampin> ... The versioning we are talking about is a versioning of the document.
14:21:12 <pchampin> ... If your application describes attributes of a person that change over time, this should be part of your data model.
14:21:24 <pchampin> ... "This is the body weight of Jesse on the 28th"
14:21:42 <pchampin> laurens: "resource versioning" might be a better description
14:21:43 <laurens> q?
14:21:48 <laurens> ack ryey
14:21:48 <Zakim> ryey, you wanted to say about metadata / aux file -- is it not in the requirements?
14:21:49 <pchampin> jesse: I will make that change
14:22:15 <pchampin> ryey: we mentioned metadata auxiliary files several times today, but I don't see this as a requirement.
14:22:22 <pchampin> ... Have I missed anything?
14:22:52 <pchampin> laurens: I'm not sure that we have a requirement related to that.
14:23:12 <pchampin> jesse: metadata auxiliary resource is a solution rather than an requirement.
14:23:30 <pchampin> ... a requirement would be "be able to describe the last-change date of the resource"
14:23:44 <pchampin> ... the auxiliary resource is a way to implement it
14:23:52 <pchampin> ryey: fair enough
14:24:41 <pchampin> ... I think that the notion should be mentioned somewhere if we use it regularly in the discussion
14:25:11 <pchampin> laurens: I'm not sure we have full coverage anyway, but PR are always welcome.
14:25:52 <laurens> q?
14:25:59 <laurens> ack gibsonf
14:25:59 <Zakim> gibsonf, you wanted to ask - maybe its as simple as adding ?date=timestamp to a request url for a previous if it exists
14:26:24 <pchampin> gibsonf1: just a thought: a simple way to spec that would be to include a datestamp in the query string
14:26:51 <pchampin> ... visible to anyone, usable by servers that implement it
14:27:02 <pchampin> laurens: this is already very concrete.
14:27:32 <pchampin> ... Quick strawpoll on the "resource versioning" requirement: we would consider it as a MAY in general, but requiring some minimal metadata
14:27:36 <otherJackson> +1 for optional (may) with an endorsement for a specific api like momento. I disagree. I think it should be in the core document
14:27:41 <TallTed> q+
14:27:46 <pchampin> jesse: I would not even write a MAY in the document; we as a group may produce an additional spec
14:27:50 <uvdsl> +1 to otherJackson's stance
14:27:51 <gibsonf1> +1 to May in core document with some guidance
14:27:58 <pchampin> s/in the document/in the core spec
14:28:07 <laurens> 0
14:28:21 <jeswr> +0
14:28:35 <TallTed> -1
14:28:37 <pchampin> +1
14:28:40 <eBremer> 0
14:28:41 <bartb> +1
14:29:14 <TallTed> q?
14:29:20 <pchampin> s/I disagree/I disagree with Jesse (below)
14:29:21 <laurens> ack TallTed
14:29:49 <pchampin> TallTed: I thought we had discussed some version of auditing earlier (23 and 24).
14:30:08 <pchampin> ... I don't think the MAY is a viable option here. We should go for SHOULD, possibly MUST.
14:30:19 <pchampin> ... Otherwise we can not achieve audit trail.
14:30:25 <ryey> 0
14:31:04 <pchampin> laurens: I'm not 100% sure you need "Resource versioning" is needed to achieve the others.
14:31:57 <pchampin> TallTed: in some situations, we may have to go to archives CDs or tapes instead of the dynamic disc.
14:32:47 <laurens> q?
14:33:12 <pchampin> laurens: this is a fair point, though I believe that depending on regulations, compliance with auditability may not always require "Resource versioning"
14:33:21 <pchampin> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-resumable-large-data-transfers Requirement: Resumable Large Data Transfers
14:33:54 <pchampin> laurens: from a technology point of view, this seems like a complex requirement.
14:34:13 <pchampin> ... This is not included in the input specifications we have.
14:34:24 <laurens> q?
14:34:28 <jeswr> q+
14:34:32 <ryey> q+
14:34:35 <laurens> ack jeswr
14:34:45 <pchampin> ... What use-cases do we see for this, beyond storing movies?
14:35:17 <pchampin> jesse: I see this as part of a separate document for Large file support, and make it optional for servers.
14:35:27 <laurens> ack ryey
14:35:37 <pchampin> ... Would also include some ways to move big files around without needing to upload them again.
14:35:54 <pchampin> ryey: Storing videos can be a big use-case for this.
14:36:04 <pchampin> ... We met this limitations recently with Solid.
14:36:06 <eBremer> q+
14:36:12 <laurens> ack eBremer
14:36:15 <pchampin> ... Part of the question is also: how large is large?
14:36:37 <pchampin> eBremer: "how large is large" is also relevant for Jesse's proposal of a separate spec.
14:36:50 <TallTed> q+
14:36:51 <pchampin> ... What is considered large today might not be in the future.
14:37:06 <pchampin> ... My use-case is about @@ that can be several GB.
14:37:17 <laurens> ack TallTed
14:37:20 <pchampin> ... I agree this should be a separate spec, as it is a moving target.
14:37:57 <pchampin> TallTed: the transfer concern should be looked at as a user telling a server to send a file to another server.
14:38:04 <eBremer> q+
14:38:09 <laurens> ack eBremer
14:38:14 <otherJackson> q+
14:38:20 <pchampin> ... It should be doable, and depends on where the large bandwidth is.
14:38:28 <pchampin> eBremer: I agree that it is another use-case.
14:38:50 <laurens> q?
14:38:52 <pchampin> ... But in my use-case, the large file is on my machine, and I want to transfer it to the storage. It can take weeks.
14:38:55 <jeswr> q+
14:38:55 <laurens> ack otherJackson
14:39:49 <pchampin> otherJackson: If the server does not want to support large files, then it should limit the size of the file.
14:39:59 <pchampin> q+
14:40:12 <laurens> ack jeswr
14:41:06 <pchampin> ... If the concern for implementing these features is to force server to support large files, then we should provide the API for the server to signal their limitations.
14:41:12 <laurens> q+
14:41:51 <pchampin> jesse: I think the server-to-server use-case is different from user-to-server, and should be kept out of scope.
14:41:56 <laurens> ack pchampin
14:41:59 <pchampin> ... There are solutions out there for this.
14:42:13 <laurens> pchampin: I wanted to reflect on the how large is large question
14:42:32 <laurens> ... I don't believe it would force servers to accept arbitrarily large files.
14:42:45 <laurens> ... a file is large if the risk of failing during the upload is high enough
14:42:54 <laurens> ... which also depends on bandwidth, storage ...
14:43:10 <laurens> ... It depends on what is large for me, which is different from person to person.
14:43:26 <laurens> ... I think it is an important feature to ensure that servers are accessible enough.
14:43:42 <laurens> q?
14:43:46 <laurens> ack laurens
14:44:11 <pchampin> laurens: I'm a bit wary of with this requirement: aren't we overstepping in IETF land?
14:44:44 <otherJackson> +1 I would say an endorsement of current standards (like range headers) in the core spec is the best.
14:44:45 <eBremer> +1
14:44:49 <uvdsl> 0
14:44:53 <gibsonf1> +1
14:44:53 <pchampin> ... Strawpoll: do we see this as a requirement on the LWS protocol
14:45:01 <jeswr> +0 as a MUST in core +1 on an optional document
14:45:11 <bartb> 0
14:45:14 <pchampin> +1 provided that we can sufficiently rely on an existing spec
14:45:19 <ryey> 0 for "must have"; but +1 for "suggested"
14:45:20 <laurens> +1
14:45:40 <bendm> +0
14:45:44 <pchampin> laurens: most responses positive or neutral so far
14:45:54 <pchampin> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-offline-access-and-synchronization Requirement: Offline Access and Synchronization
14:46:45 <pchampin> jesse: my understanding is that it is a requirement to support CRDTs as part of the specification
14:46:50 <pchampin> ... my view is that we should not
14:46:58 <ryey> q+
14:47:03 <laurens> ack ryey
14:47:25 <pchampin> ryey: I agree with Jesse. CRDT themselves should not be part of the spec as a necessity.
14:47:33 <laurens> q?
14:47:40 <eBremer> +1 "I agree with Jesse. CRDT themselves should not be part of the spec as a necessity."
14:47:43 <pchampin> ... However, some mechanisms should exist in the protocol to allow CRDTs in an easy way.
14:47:55 <pchampin> ... (as opposed to very weird ways)
14:48:05 <pchampin> otherJackson: can you explain what these weird ways are?
14:48:26 <pchampin> ryey: @@ currently stores the CRDT history into your pod
14:49:21 <pchampin> jesse: this is similar to the discussion on versioning; we could store different versions of a given resource in a container.
14:49:31 <laurens> q?
14:49:40 <pchampin> ... If your server has a CRDT API, it can serve the latest version via the LWS API,
14:49:45 <jeswr> -1
14:49:47 <pchampin> ... but LWS should not mandate the CRDT API.
14:49:48 <gibsonf1> -1
14:49:49 <eBremer> -1
14:49:50 <bendm> -1
14:49:50 <laurens> -1
14:49:50 <TallTed> speaking of concerns involving large resources! 2 intact versions of BigFile could overwrite storage, where changelogging might consumes only a few extra KB!
14:49:53 <bartb> -1
14:49:55 <ryey> -1
14:49:55 <otherJackson> -1 for a required +1 OPTIONAL endorsement of a CRDT api
14:50:04 <uvdsl> -1
14:50:07 <pchampin> -1
14:50:08 <TallTed> q+
14:50:17 <laurens> ack TallTed
14:51:32 <laurens> q?
14:51:33 <pchampin> TallTed: holding multiple copies of a large document will be costly.
14:52:10 <pchampin> laurens: I see mostly -1s, so we can strike out this requirement
14:52:16 <pchampin> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-serialization-format Requirement: Serialization Format
14:52:27 <pchampin> laurens: this one seems quite a no-brainer
14:53:05 <pchampin> jesse: I'm finding the wording confusing. Is it "we should conteng-negociate RDF"?
14:53:13 <pchampin> ... My position is that we should support content-type headers.
14:53:26 <pchampin> ... We should not mandate conneg for RDF content types in the core spec.
14:53:41 <TallTed> q+
14:53:59 <pchampin> ... To allow others to use the spec.
14:54:01 <laurens> ack TallTed
14:54:22 <pchampin> TallTed: I would like to MUST content-negociation, but I would be ok with a should.
14:54:34 <pchampin> ... We want to encourage people who do not use RDF to do so.
14:54:58 <pchampin> ... Part of content-negociation is "give me this if you have it", part of it is "give me this if you can convert to it".
14:55:24 <laurens> q?
14:55:25 <ryey> q+ to ask what is implied in content negotiation in RDF? also not exactly understand Jesse's comment just now
14:55:30 <laurens> ack Ryey
14:55:30 <Zakim> ryey, you wanted to ask what is implied in content negotiation in RDF? also not exactly understand Jesse's comment just now
14:55:35 <pchampin> ... There is no point in serving a JPEG file in RDF, but the resource describing its history might/should be in RDF.
14:56:00 <pchampin> ryey: I wonder what content-negociation implies for RDF?
14:56:07 <pchampin> ... Conversion across RDF formats, or more?
14:56:49 <TallTed> q+
14:56:54 <pchampin> jesse: supporting content-type headers could be "I know this is text/turtle because that's how it was sent to me, but I don't know how to content-negogiate it"
14:57:21 <pchampin> ... the former could be described in a separate document, which would not be required of all servers
14:57:45 <pchampin> ... That gives room to define similar documents for other kinds of content-types (withing this group or another group).
14:57:54 <laurens> ack TallTed
14:58:11 <pchampin> TallTed: content-negociation does not imply content translation.
14:58:29 <pchampin> ... The client says "I want one of these formats", the server has complete control over what happens next.
14:58:53 <pchampin> ... [describes multiple ways the server can behave]
14:58:58 <pchampin> q+
14:59:11 <laurens> q?
14:59:18 <laurens> ack pchampin
14:59:38 <TallTed> s/content-negociation/content-negotiation/
14:59:46 <laurens> pchampin: I'm a big fan of content negotiation, a few years ago i would have said this should be a must.
14:59:51 <TallTed> s/content-negogiate/content-negotiate/
15:00:03 <laurens> ... but things can be tricky in a read-write environment (e.g. with PUT)
15:00:10 <TallTed> s/content-negociation/content-negotiation/g
15:00:12 <laurens> ... so I would be in favor of a SHOULD
15:00:29 <laurens> ... I would like the content negotiation to be driven from the client.
15:00:48 <laurens> ... Apache has this feature, and this would be nice.
15:00:58 <laurens> ... The server doesn't have to take the burden.
15:02:16 <pchampin> laurens: jesse, could you maybe rephrase this requirement, mentioning content-negociation, to discuss it in 2 weeks
15:02:19 <pchampin> RRSAgent, make minutes
15:02:21 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/11-lws-minutes.html pchampin
15:02:58 <ryey> s/@@ currently stores the CRDT history into your pod/Soukai currently stores the CRDT history into your pod/
15:04:11 <pchampin> s/is about @@ that/is about digital whole slide images (WSI) that
15:04:15 <pchampin> RRSAgent, make minutes
15:04:16 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/11-lws-minutes.html pchampin
15:04:39 <pchampin> present+ ryey
15:04:41 <pchampin> RRSAgent, make minutes
15:04:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/11-lws-minutes.html pchampin
15:06:26 <pchampin> i|pchampin: There is something|scribe+ laurens
15:06:34 <pchampin> i|I would support saying|scribe- laurens
15:06:36 <pchampin> RRSAgent, make minutes
15:06:37 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/11-lws-minutes.html pchampin
15:07:08 <pchampin> i|pchampin: I wante|scribe+ laurens
15:07:20 <pchampin> i|I'm a bit wary of with|scribe- laurens
15:07:24 <pchampin> RRSAgent, make minutes
15:07:25 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/11-lws-minutes.html pchampin
15:07:59 <pchampin> i|I'm a big fan of content|scribe+ laurens
15:08:03 <pchampin> RRSAgent, make minutes
15:08:04 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/11-lws-minutes.html pchampin
15:08:17 <pchampin> zakim, end meeting
15:08:17 <Zakim> As of this point the attendees have been gibsonf, TallTed, pchampin, eBremer, bartb, laurens, otherJackson, uvdsl, jesse, ryey
15:08:19 <Zakim> RRSAgent, please draft minutes
15:08:20 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/11-lws-minutes.html Zakim
15:08:26 <Zakim> I am happy to have been of service, pchampin; please remember to excuse RRSAgent.  Goodbye
15:08:26 <Zakim> Zakim has left #lws