12:33:41 <RRSAgent> RRSAgent has joined #lws
12:33:45 <RRSAgent> logging to https://www.w3.org/2025/08/04-lws-irc
12:33:45 <Zakim> Zakim has joined #lws
12:34:06 <TallTed> meeting: Linked Web Storage WG
12:34:08 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
12:35:00 <TallTed> previous meeting: https://www.w3.org/2025/07/28-lws-minutes.html
12:35:00 <TallTed> next meeting: https://www.w3.org/2025/08/11-lws-minutes.html
12:35:23 <TallTed> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250804T100000/
12:35:24 <agendabot> clear agenda
12:35:24 <agendabot> agenda+ Introductions and announcements
12:35:24 <agendabot> agenda+ Action Items
12:35:24 <agendabot> agenda+ Continued clarification of requirements
12:35:31 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
13:01:13 <dmitriz> dmitriz has joined #lws
13:43:59 <acoburn> acoburn has joined #lws
13:53:14 <TallTed> present+
13:53:25 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
13:59:32 <acoburn> agenda?
13:59:45 <acoburn> chair: acoburn
14:01:39 <acoburn> zakim, start meeting
14:01:39 <Zakim> RRSAgent, make logs Public
14:01:41 <Zakim> please title this meeting ("meeting: ..."), acoburn
14:01:46 <bendm> bendm has joined #lws
14:01:50 <bendm> present+
14:01:51 <gibsonf1> gibsonf1 has joined #lws
14:02:03 <laurens> laurens has joined #lws
14:02:05 <acoburn> meeting: Linked Web Storage Meeting 2025-08-04 -- Agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250804T100000/
14:02:06 <gibsonf1> +present
14:02:07 <laurens> present+
14:02:11 <gibsonf1> present+
14:02:12 <acoburn> present+
14:02:15 <hadrian> hadrian has joined #lws
14:02:44 <TallTed> s| -- Agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250804T100000/||
14:02:49 <hadrian> present+
14:02:52 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
14:03:11 <eBremer> eBremer has joined #lws
14:03:17 <eBremer> present+
14:03:34 <laurens> scribe: laurens
14:03:36 <TallTed> s/Meeting 2025-08-04/WG Meeting/
14:03:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
14:04:01 <acoburn> zakim, open agendum 1
14:04:01 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
14:04:23 <TallTed> s/+present/present+/
14:04:31 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
14:04:37 <Monsecom> Monsecom has joined #lws
14:04:45 <Monsecom> present+
14:04:56 <laurens> acoburn: Anyone new in this meeting?
14:05:21 <laurens> q+
14:05:30 <laurens> laurens: Face-to-face meeting in Ghent, BE hosted by Digitaal Vlaanderen on October 8-10, 2025. Details have been sent out via the mailing list.
14:05:30 <acoburn> scribe+
14:05:35 <acoburn> ack next
14:05:57 <acoburn> laurens: f2f meeting will be hosted in Belgium Oct 8-10. Details sent out via mailing list
14:06:06 <acoburn> ... please confirm attendance by Aug 29
14:06:22 <acoburn> ... there is also an option to indicate that you will attend remotely
14:06:33 <acoburn> ... we encourage in-person attendance
14:07:07 <acoburn> ... there will likely be 1 or 2 more f2f meetings for this WG, so there will be other opportunities if this meeting doesn't work
14:07:11 <acoburn> scribe-
14:07:37 <pchampin> present+
14:07:51 <laurens> jeswr: On August 18 the chairs will be out-of-office
14:08:06 <laurens> ... So I would like to focus on the topic of authz in that week
14:08:19 <laurens> ... I am designing an authz system I would like to propose to the group
14:08:37 <laurens> ... which works with the as-is requirements as well as ABAC (attribute based access control)
14:09:04 <TallTed> q+
14:09:06 <laurens> ... I am trying to work this out. By August 18 I would like to go through an ontology for this.
14:09:12 <acoburn> ack next
14:10:06 <acoburn> zakim, open agendum 2
14:10:06 <Zakim> agendum 2 -- Action Items -- taken up [from agendabot]
14:10:32 <laurens> acoburn: I don't think we have any action items listed in Github
14:10:49 <laurens> ... Folks have been moving through specific action items on merging or specifying requirements.
14:10:58 <laurens> ... Any action items we should anticipate in the next week?
14:11:13 <acoburn> zakim, open agendum 3
14:11:13 <Zakim> agendum 3 -- Continued clarification of requirements -- taken up [from agendabot]
14:11:44 <TallTed> s|Details sent out via mailing list| Details sent out via mailing list -- https://lists.w3.org/Archives/Member/member-lws-wg/2025Aug/0000.html
<laurens> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-end-to-end-encryption-0 Requirement 21 End-to-End Encryption
14:11:49 <laurens> acoburn: This is the editor's draft document for UC&R
14:11:54 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
14:12:06 <laurens> ... We will start with requirement 21 "End-to-end encryption"
14:12:28 <laurens> ... We should ideally finish this next week.
14:12:50 <laurens> ... Try not to solve any of these issues, but focusing on whether they are in-scope or out-of-scope.
14:13:16 <jeswr> jeswr has joined #lws
14:13:22 <jeswr> present+
14:13:24 <jeswr> +1
14:13:26 <laurens> ... On 21 "End-to-end encryption", I think this will probably be out-of-scope from a protocol perspective
14:13:27 <bendm> +1
14:13:27 <laurens> +1
14:13:33 <eBremer> +1
14:13:41 <gibsonf1> +1
14:13:48 <TallTed> +1
14:13:59 <otherJackson> otherJackson has joined #lws
14:14:06 <TallTed> s/Try not to solve/Not trying to solve/
<laurens> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-self-descriptive-and-discoverable-apis Requirement 20 Self-Descriptive and Discoverable APIs
14:14:08 <laurens> ... Let's move on to 20 "Self Descriptive and Discoverable APIs"
14:14:37 <gibsonf1> +1
14:14:41 <laurens> ... The protocol document currently has specific focus on discoverability so this will probably be important.
14:14:49 <laurens> +1
14:14:50 <bendm> +1
14:14:51 <eBremer> +1
14:14:53 <jeswr> +1
14:15:08 <TallTed> +1
<laurens> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-search-and-query Requirement 19 Search and Query
14:15:21 <laurens> ... This is going well so far, so let's move to 19 "Search and Query"
14:15:32 <TallTed> q+
14:15:47 <laurens> ... I want to be careful on this on, we could easily spend the entire meeting on this.
14:15:54 <jeswr> q+
14:15:54 <acoburn> ack next
14:16:07 <laurens> TallTed: It appears that these are straw polls not resolutions.
14:16:15 <laurens> acoburn: These are indeed straw polls.
14:16:34 <laurens> acoburn: With query I want to dig in this a little bit, but stay at a high level.
14:16:37 <acoburn> ack next
14:16:55 <laurens> jeswr: I would like to propose that we break this down as follows
14:17:06 <laurens> ... at present Erich and I are working on read and write operations
14:17:09 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
14:17:16 <laurens> ... And I am working on the authz parts
14:17:59 <laurens> ... I suggest we have a second specification document within the scope of LWS, which supports other types of content negotiation or any type of search that are supported.
14:18:11 <laurens> ... Servers could choose to support or not to support such features.
14:18:31 <laurens> ... These separate specifications could define type indexes, SPARQL, ... .
14:18:48 <laurens> ... I want to straw poll which types of search interfaces should be supported.
14:19:05 <laurens> ... Do we have other search specifications that should be considered?
14:19:23 <gibsonf1> q+
14:19:41 <laurens> acoburn: How do we structure this?
14:19:53 <laurens> jeswr: Let's go through them one by one...
14:19:58 <laurens> ... starting with type indexes.
14:20:10 <laurens> ... Should type indexes be included in the server spec?
14:20:18 <acoburn> ack next
14:20:30 <jeswr> jeswr has joined #lws
14:20:58 <laurens> gibsonf1: We are using key-value, intersection of sets based querying (cfr. Apache Solr)
14:21:08 <otherJackson> Quick question on type index: would this be as implemented, or could this "some form of type index" be something auto-generated?
14:21:12 <laurens> acoburn: Should some form of type indexes be supported in the server spec?
14:21:16 <laurens> -1
14:21:22 <jeswr> +0
14:21:22 <acoburn> +1
14:21:35 <gibsonf1> -1
14:21:41 <eBremer> +0
14:21:48 <TallTed> -0.5 (I'm not firmly convinced, but leaning against)
14:21:49 <bendm> +0
14:21:52 <laurens> jeswr: I would believe such indexes to be managed by the server
14:21:54 <pchampin> +0
14:22:01 <otherJackson> -1
14:22:20 <laurens> jeswr: There seams to be a slight lean against this option.
14:22:39 <laurens> acoburn: Should full SPARQL querying be supported in the server spec?
14:22:45 <jeswr> +0.5 (as separate spec document, optional implementation)
14:23:01 <otherJackson> +1 (as long as it's optional and it has auth enforcement)
14:23:08 <acoburn> -1 (as a requirement) +0 (as an optional feature)
14:23:15 <eBremer> +1 (as an option)
14:23:19 <gibsonf1> +0 on Sparql (Sparql is just very complex and too hard for people to learn)
14:23:20 <bendm> +0 (same as jesse, I think the discoverability of those affordances are more important than the actual affordances)
14:23:25 <laurens> -1 (as requirement) +0 (as option)
14:23:26 <TallTed> =0.8 (as requirement, this would substantially lower the implementation count ... won't impact Virtuoso, as it's built in)
14:23:55 <dmitriz> present+
14:24:03 <gibsonf1> +1 on optional but not required
14:24:03 <otherJackson> present+
14:24:07 <pchampin> -1 (as a requirement) +0 (as an optional feature)
14:24:10 <laurens> jeswr: Desireable as an optional feature, probably not as a requirement.
14:24:19 <TallTed> s/leaning against/leaning against ... won't impact Virtuoso, as it's built in/
14:24:33 <otherJackson> q+
14:24:53 <laurens> acoburn: Do members of the group have other querying interfaces to propose (RDF or non-RDF)?
14:24:56 <acoburn> ack next
14:25:20 <laurens> otherJackson: I think QPF could be another interface to consider
14:25:48 <laurens> ... Additionally have we considered notifications for indexes? While leaving the actual index out-of-spec.
14:25:50 <TallTed> (what is QPF?)
14:26:07 <jeswr> QPF: https://linkeddatafragments.org/specification/quad-pattern-fragments/
14:26:24 <laurens> acoburn: Quad pattern fragments (or triple pattern fragments) allows for matching against simple patterns in RDF.
14:26:51 <laurens> ... Let's consider solutions at a later point, but leave that separate. There is a topic on inter-user communication which will come later.
14:27:12 <laurens> jeswr: Should QPF querying be supported in the server spec?
14:27:19 <gibsonf1> -1
14:27:27 <dmitriz> QPR - -1 to required, +1 as optional
14:27:27 <acoburn> -1 (as a requirement) +0 (as optional)
14:27:32 <pchampin> -1 (as a requirement) +0 (as an optional feature)
14:27:33 <eBremer> +1 (as an option)
14:27:38 <TallTed> s/supported/required/
14:27:39 <laurens> +0.5 (as optional feature) -1 (as requirement)
14:27:41 <bendm> +0
14:27:42 <otherJackson> -0.5 to required +1 as optional
14:27:52 <TallTed> -1
14:28:56 <laurens> acoburn: Leans positive as an optional feature.
14:29:12 <jeswr> q+
14:29:15 <laurens> acoburn: Let's jump to other kinds of interfaces (like Frederick's suggestion)
14:29:21 <acoburn> ack next
14:29:41 <laurens> jeswr: Does gibsonf1 have an existing specification of such a querying mechanism?
14:29:48 <laurens> gibsonf1: Looking into it.
14:29:54 <TallTed> (again, QPF won't impact Virtuoso, as it's built in -- https://docs.openlinksw.com/virtuoso/rdfviewquadmapatternsvalueandiriclasses/)
14:30:29 <dmitriz> i read 'optional' as exactly that - extensions, discoverable etc
14:30:33 <laurens> acoburn: We have been discussing optional and required. But there is also a third option, for features that are optional but could be discovered on a server to server basis.
14:30:56 <laurens> ... How can we make affordances such that implementations can pursue alternative interfaces but still have some interop.
14:31:00 <otherJackson> I feel like option is directly mentioned in the spec, whereas "extension" wouldn't be mentioned.
14:31:25 <gibsonf1> https://solr.apache.org/guide/solr/latest/query-guide/common-query-parameters.html
14:31:33 <dmitriz> @otherJackson - i see, ok. i'll adopt that terminology as well
14:32:04 <laurens> acoburn: We should be careful about hard bindings to specific implementations.
14:32:11 <gibsonf1> q+ to say on query...
14:32:20 <acoburn> ack next
14:32:21 <Zakim> gibsonf, you wanted to say on query...
14:32:36 <laurens> gibsonf1: We're not actually using the raw apache solr for the user
14:32:49 <TallTed> Loose coupling is key across the board.
14:32:49 <laurens> ... It is a simplified approach for the user, that is very powerful.
14:33:03 <laurens> ... The backend is using apache, but the frontend is simplified.
14:33:24 <laurens> ... We also have a secondary mechanism (tag search), which allows to find related documents.
14:33:33 <laurens> ... Those are our two basics.
14:33:39 <laurens> ... We have that in production.
14:34:23 <dmitriz> we should have extensible query mechanisms
14:34:29 <otherJackson> -1 to required -0.8 to optional +1 to an "extension" based system with required content negotiation
14:34:44 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html TallTed
14:34:50 <laurens> acoburn: Should there be an affordance for supporting alternative query interfaces in the protocol?
14:34:51 <laurens> +0.5
14:34:53 <gibsonf1> +1
14:34:56 <jeswr> +0.5
14:34:59 <bendm> q+
14:34:59 <eBremer> +1
14:35:01 <pchampin> +1
14:35:06 <acoburn> ack next
14:35:09 <dmitriz> +1 to the _affordance_ / discoverability of any query mechanism
14:35:16 <TallTed> s/=0.8/-0.8/
14:35:36 <laurens> bendm: Unclear what this straw poll is about.
14:35:52 <laurens> acoburn: This is about the discoverability of the interface, not the interface itself.
14:35:57 <bendm> +1
14:36:02 <acoburn> +1 (for discoverability)
14:36:16 <otherJackson> q+
14:36:49 <laurens> acoburn: When we get into the details of how this requirement is expressed in the protocol, there will be aspects related to pagination, ... that have to be resolved.
14:36:50 <acoburn> ack next
14:37:53 <laurens> otherJackson: Two more things to consider would be (a) support for an easier data dump that doesn't require traversing the hierarchy of resources and (b) (more of a thought) I think we would want some kind of requirement to search and discover things across documents
14:38:05 <laurens> ... Something like QPF or SPARQL would be quite intense to support.
14:38:07 <gibsonf1> q+ to say, I'm assuming query is not only accross documents but any data and any pods on server
14:38:15 <laurens> ... But having some kind of baseline might be helpful.
14:38:20 <acoburn> ack next
14:38:21 <Zakim> gibsonf, you wanted to say, I'm assuming query is not only accross documents but any data and any pods on server
14:38:44 <laurens> gibsonf1: My idea on search is that this would resolve any data on any pod on that server.
14:39:28 <laurens> acoburn: I feel like there is a category of bulk operations, but it might be a bad match right now.
14:39:37 <laurens> ... Right now we don't have a lot of clarity on this.
14:39:44 <laurens> ... But it could fit under that heading.
14:40:19 <laurens> jeswr: I know that eBremer has been working on CRUD interfaces, which could include some of these large file interfaces.
14:40:38 <bendm> q+ to ask about having a listing dump (which could bring the affordance to any kind of index operations)
14:40:55 <gibsonf1> q+ to say including a results spec in the query very important for large scale
14:40:59 <acoburn> ack next
14:41:00 <Zakim> bendm, you wanted to ask about having a listing dump (which could bring the affordance to any kind of index operations)
14:41:01 <laurens> ... I propose we don't do this in the context of the large file operations, but discuss this separately next week related specifically to CRUD operations.
14:41:24 <laurens> bendm: I have the feeling we need a requirement to dump the resource listing managed in the storage server.
14:41:32 <laurens> ... That would allow for external indexing and querying.
14:41:59 <laurens> acoburn: Could you open a PR on the UCR to add that req?
14:42:07 <otherJackson> +1 to Ben's use case on discovering available documents
<laurens> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-inter-user-communication Requirement 18 Inter-User Communication
14:42:21 <laurens> acoburn: Let's move to 18 "Inter-User Communication"
14:42:42 <laurens> ... This is about an agent that can subscribe to messages about changes on a set of resources.
14:42:52 <laurens> ... e.g. I want to know about changes on a resource or container.
14:42:58 <TallTed> so more "change tracking" than "inter-user commms"?
14:43:22 <laurens> acoburn: Change tracking would be one use-case for this.
14:43:43 <gibsonf1> +1 (assuming this is an inbox kind of spec)
14:43:47 <laurens> ... Unsure if change tracking is sufficiently generic here.
14:43:50 <TallTed> feels like activitypub/activitystreams
14:44:24 <laurens> acoburn: This should also include changes on auxiliary resources (e.g. comments, ACLs)
14:44:26 <TallTed> "subscribe to (changes to) Doc_X"
14:44:39 <laurens> s/acoburn: This should also include changes on auxiliary resources (e.g. comments, ACLs)/jeswr: This should also include changes on auxiliary resources (e.g. comments, ACLs)/
14:44:40 <otherJackson> +1 to change tracking
14:44:48 <pchampin> +1 "change tracking" is better than "inter-user com"
14:44:54 <bendm> +1
14:44:56 <laurens> +1 to change tracking
14:44:56 <eBremer> +1
14:44:57 <dmitriz> +1 to change tracking
14:45:06 <jeswr> +1 change tracking
14:45:08 <acoburn> +1 to change tracking
14:45:19 <gibsonf1> +1  change tracke (and +1 on an inbox spec for inter-user comms)
14:45:30 <otherJackson> q+
14:45:35 <laurens> acoburn: This appears to be positive support on this.
14:45:37 <TallTed> +0.8 (certainly, extension/option; not so much about requirement ... and again probably already built in to Virtuoso)
14:45:39 <acoburn> ack next
14:45:40 <Zakim> gibsonf, you wanted to say including a results spec in the query very important for large scale
14:45:46 <dmitriz> @TallTed - re "feels like AP/AS2" -- so that could be one of the implementation details / mechanisms, for change tracking.
14:45:47 <acoburn> ack next
14:46:05 <dmitriz> @TallTed -- but also of course WebSub
14:46:44 <laurens> otherJackson: Related but disjoined from change-tracking, but when access controls are changed that agent should be notified. This is distinct from change tracking as the agent could previously not have access to that resource.
14:47:02 <gibsonf1> +1 on making it more than just change-tracking, and an inbox kind of spec to handle all
14:47:08 <laurens> acoburn: This is something we need to clarify in the specification.
14:47:18 <laurens> ... Or do we need to clarify this now?
14:47:21 <ryey> ryey has joined #lws
14:47:27 <ryey> present+
<laurens> subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-contextual-access-control Requirement 17 Contextual Access Control
14:47:43 <laurens> acoburn: Let's move to 17 "Contextual Access Control"
14:48:59 <laurens> jeswr: There are well known types of access control, currently they are largely role based access control.
14:49:05 <TallTed> so "access policies" or "attribute-based access control", to use more common labels?
14:49:38 <TallTed> s/access policies/policy-based access control/
14:49:46 <laurens> ... There is also attribute based access controls, e.g. access grants in ACP specification
14:49:46 <laurens> q+
14:50:11 <laurens> ... I think that within this group we would want to have actual attributes of the person (e.g. in a VC) to be used.
14:50:36 <laurens> ... For example in the case of age restrictions, the authorization server might check that someone is over 18.
14:51:08 <laurens> ... In addition to role and attribute I think we will also potentially want to support capability delegation (e.g. ZCap).
14:51:51 <laurens> ... The question for the 18th will be, do we want role and attribute based access control potentially with capability delegation.
14:52:01 <laurens> ... Do we want attribute based access control?
14:52:31 <dmitriz> I think the question should be - just like with everything else (query mechanisms, notifications, etc) -- providing affordances for extensible authorization mechanisms
14:52:32 <laurens> ... Do we want capability delegation (i.e. the authorization server saying that Aaron has the capability to hand out permissions)?
14:52:36 <acoburn> ack next
14:53:01 <acoburn> scribe+
14:53:28 <jeswr> jeswr has joined #lws
14:53:35 <dmitriz> q+
14:53:56 <pchampin> q+
14:54:13 <acoburn> laurens: in WAC/ACP we have discretionary access control. I would not quite call it role based. Attribute access control is complicated and I'd want to clarify role based first
14:54:22 <acoburn> scribe-
14:54:24 <acoburn> ack next
14:54:48 <laurens> dmitriz: I wanted to propose that instead of discussing which authz mechanism, we should just focus on an extensible, discoverable mechanism.
14:54:49 <ryey> q+ on the extent of / complexity of access control mechanism to be supported in the spec; maybe basic ones + permission delegation as baseline, with extensibility possibility; also on single spec or more
14:54:54 <acoburn> q?
14:54:55 <laurens> ... And provide affordances.
14:55:05 <laurens> ... We need the extensibility as mechanisms will come and go.
14:55:05 <acoburn> ack next
14:55:11 <TallTed> (fwiw ... ABAC is built in for Virtuoso Enterprise, not available for Virtuoso Open Source ... RBAC is built in for both)
14:55:56 <laurens> pchampin: I am not sure whether there has been enough incubation on this topic in Solid. It may have been incubated in other efforts. I would be mindful of sufficient incubation.
14:56:04 <gibsonf1> +1 on extensible
14:56:06 <acoburn> ack next
14:56:07 <Zakim> ryey, you wanted to comment on the extent of / complexity of access control mechanism to be supported in the spec; maybe basic ones + permission delegation as baseline, with
14:56:07 <Zakim> ... extensibility possibility; also on single spec or more
14:56:33 <laurens> ryey: To what extend do we want to support a complex access control mechanism in v1 of the specification.
14:56:46 <laurens> ... Should the access control mechanism be a secondary specification to the core protocol.
14:57:22 <laurens> ... One practical thing I could think of is to maybe support some basic principals (e.g. role based, group based, ...) and in addition support permission delegation.
14:57:24 <acoburn> RRSAgent, make minutes
14:57:26 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html acoburn
14:57:32 <dmitriz> +1 to what ryey says -- separate specs / extension points
14:58:03 <laurens> acoburn: We are at time.
14:58:23 <laurens> ... I feel like access control will be part of the spec, but we will have to define the scope of it.
14:58:44 <gibsonf1> +1 on base level that all servers comply with for interop
14:58:49 <otherJackson> +1 to certain required specs
14:58:49 <pchampin> +1
14:58:50 <dmitriz> agree, yeah.
14:58:54 <laurens> ... 15, 16 and 17 should probably be part in some way of the specification?
14:58:59 <eBremer> +1
14:59:00 <bendm> +1 on a bases, yes
14:59:05 <laurens> +0.8 (for the most part)
14:59:30 <laurens> acoburn: For 14 we should consider if it is a duplicate of inter-user communication.
14:59:35 <TallTed> +1 for LWS as a concept to work, it will require some form of each of those items (which we should be referencing by name, not number)
15:00:05 <acoburn> RRSAgent, make minutes
15:00:07 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html acoburn
15:00:43 <acoburn> acoburn has left #lws
15:01:57 <TallTed> Zakim, end meeting
15:01:57 <Zakim> As of this point the attendees have been TallTed, bendm, present, laurens, gibsonf, acoburn, hadrian, eBremer, Monsecom, pchampin, jeswr, dmitriz, otherJackson, ryey
15:02:00 <Zakim> RRSAgent, please draft minutes
15:02:01 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/04-lws-minutes.html Zakim
15:02:08 <Zakim> I am happy to have been of service, TallTed; please remember to excuse RRSAgent.  Goodbye
15:02:08 <Zakim> Zakim has left #lws
15:02:08 <TallTed> RRSAgent, bye
15:02:08 <RRSAgent> I see no action items