13:54:02 <RRSAgent> RRSAgent has joined #lws
13:54:07 <RRSAgent> logging to https://www.w3.org/2026/08/17-lws-irc
13:54:30 <acoburn> acoburn has changed the topic to: Linked Web Storage - 2026-08-17 - https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260817T100000/
13:54:36 <acoburn> zakim, start meeting
13:54:36 <Zakim> RRSAgent, make logs Public
13:54:38 <Zakim> please title this meeting ("meeting: ..."), acoburn
13:54:44 <acoburn> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260817T100000/#agenda
13:54:44 <agendabot> clear agenda
13:54:44 <agendabot> agenda+ Introduction and announcements
13:54:44 <agendabot> agenda+ Vote: Publish FPWD of -> Webhooks Notification Suite https://w3c.github.io/lws-protocol/lws10-notifications-webhook/
13:54:44 <agendabot> agenda+ Vote: Publish FPWD of -> LWS Index Services https://w3c.github.io/lws-protocol/lws10-searchindex/
13:54:45 <agendabot> agenda+ Vote: Integrate access request terminology -> PR#218 https://github.com/w3c/lws-protocol/pull/218
13:54:48 <agendabot> agenda+ Vote: Replace AS terms with DCTerms/LWS equivalents -> PR#219 https://github.com/w3c/lws-protocol/pull/219
13:54:51 <agendabot> agenda+ Vote: Remove the Slug Header requirements -> PR#224 https://github.com/w3c/lws-protocol/pull/224
13:54:54 <agendabot> agenda+ Vote: Add subject_uri_schemes_supported to AS metadata -> PR#227 https://github.com/w3c/lws-protocol/pull/227
13:54:57 <agendabot> agenda+ Vote: Clarify OAuth best practices -> PR#225 https://github.com/w3c/lws-protocol/pull/225
13:54:57 <acoburn> meeting: Linked Web Storage
13:55:00 <agendabot> agenda+ Vote (maybe): Remove the ETag requirements -> PR#228 https://github.com/w3c/lws-protocol/pull/228
13:55:01 <acoburn> chair: acoburn
13:55:03 <agendabot> agenda+ Discussion: Decide on resolution for StorageResource definition -> issue#220 https://github.com/w3c/lws-protocol/pull/220
13:55:07 <agendabot> agenda+ Discussion: Decide what to do with ssi-did-key document -> PR#226 https://github.com/w3c/lws-protocol/pull/226
13:55:10 <agendabot> agenda+ Discussion: Implementation feedback
13:55:11 <acoburn> rrsagent, make minutes
13:55:13 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/17-lws-minutes.html acoburn
13:55:38 <acoburn> previous meeting: https://www.w3.org/2026/08/10-lws-minutes.html
13:55:48 <TallTed> TallTed has joined #lws
13:55:50 <acoburn> next meeting: https://www.w3.org/2026/08/24-lws-minutes.html
13:55:55 <acoburn> rrsagent, make minutes
13:55:56 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/17-lws-minutes.html acoburn
13:58:04 <elf-pavlik> elf-pavlik has joined #lws
13:59:18 <pchampin> present+
13:59:32 <acoburn> present+
13:59:51 <eBremer> eBremer has joined #lws
13:59:55 <eBremer> present+
14:02:12 <elf-pavlik> present+
14:02:25 <TallTed> present+
14:02:39 <ericP> ericP has joined #lws
14:02:43 <gibsonf1> gibsonf1 has joined #lws
14:02:44 <ericP> present+
14:02:49 <gibsonf1> present+
14:03:00 <ericP> scribe: ericP
14:03:18 <acoburn> zakim, open agendum 1
14:03:18 <Zakim> agendum 1 -- Introduction and announcements -- taken up [from agendabot]
14:03:50 <acoburn> zakim, next agendum
14:03:50 <Zakim> agendum 1 was just opened, acoburn
14:03:59 <acoburn> zakim, next agendum
14:03:59 <Zakim> agendum 1 was just opened, acoburn
14:04:11 <acoburn> zakim, open agendum 2
14:04:11 <Zakim> agendum 2 -- Vote: Publish FPWD of -> Webhooks Notification Suite https://w3c.github.io/lws-protocol/lws10-notifications-webhook/ -- taken up [from agendabot]
14:05:02 <ericP> acoburn: we have a number of votes; two docs not yet published: webhooks and lws search services.
14:05:43 <rbreitman> rbreitman has joined #lws
14:05:49 <rbreitman> present+
14:06:10 <ericP> ... Lawrence moved the webhooks part into its own seprate document
14:06:21 <acoburn> https://w3c.github.io/lws-protocol/lws10-notifications-webhook/
14:06:21 <ericP> ... this allows for extension points
14:06:55 <ericP> ... this webhooks portion is currently unpublished
14:06:57 <acoburn> PROPOSAL: Publish the FPWD of the Webhooks Notification Suite based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-notifications-webhook/
14:06:59 <elf-pavlik> +1
14:07:02 <ericP> +1
14:07:09 <pchampin> +1
14:07:10 <acoburn> +1
14:07:13 <eBremer> +1
14:07:14 <gibsonf1> +1
14:07:18 <TallTed> +1
14:07:36 <acoburn> RESOLVED: Publish the FPWD of the Webhooks Notification Suite based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-notifications-webhook/
14:07:46 <acoburn> zakim, open agendum 3
14:07:46 <Zakim> agendum 3 -- Vote: Publish FPWD of -> LWS Index Services https://w3c.github.io/lws-protocol/lws10-searchindex/ -- taken up [from agendabot]
14:08:17 <ericP> acoburn: search and type index services has not been published
14:08:28 <ericP> ... vote is to go to FPWD
14:08:59 <acoburn> PROPOSAL: Publish the FPWD of the Search and Type Index Services based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-searchindex/
14:08:59 <ericP> ... for both this and the previous, we can decided whether to go on the REC track or stay in permanent CR
14:09:02 <gibsonf1> +1
14:09:03 <elf-pavlik> +1
14:09:04 <eBremer> +1
14:09:07 <ericP> +1
14:09:09 <acoburn> +1
14:09:11 <pchampin> +1
14:09:21 <TallTed> +1
14:09:24 <ryey> ryey has joined #lws
14:09:29 <ryey> present+
14:09:47 <acoburn> RESOLVED: Publish the FPWD of the Search and Type Index Services based on the editor's draft at https://w3c.github.io/lws-protocol/lws10-searchindex/
14:09:54 <acoburn> zakim, open agendum 4
14:09:54 <Zakim> agendum 4 -- Vote: Integrate access request terminology -> PR#218 https://github.com/w3c/lws-protocol/pull/218 -- taken up [from agendabot]
14:11:40 <acoburn> PROPOSAL: Merge the access request terminology PR at https://github.com/w3c/lws-protocol/pull/218
14:11:41 <gb> https://github.com/w3c/lws-protocol/pull/218 -> PR 218 Integrate access request terminology with main terminology section (by acoburn) [editorial] [access-request]
14:11:43 <elf-pavlik> +1
14:11:44 <ericP> acoburn: this PR noves terms to Terminology. (these terms were left inline to minimize diffs when the lower section was added)
14:11:46 <eBremer> +1
14:11:48 <ryey> +1
14:11:49 <acoburn> +1
14:11:50 <ericP> +1
14:11:51 <gibsonf1> +1
14:11:51 <pchampin> +1
14:12:07 <TallTed> +1
14:12:19 <acoburn> RESOLVED: Merge the access request terminology PR at https://github.com/w3c/lws-protocol/pull/218
14:12:29 <acoburn> zakim, open agendum 5
14:12:29 <Zakim> agendum 5 -- Vote: Replace AS terms with DCTerms/LWS equivalents -> PR#219 https://github.com/w3c/lws-protocol/pull/219 -- taken up [from agendabot]
14:13:33 <ericP> acoburn: we were using ActivityStreams for Containers even though they aren't ActivityStreams
14:13:49 <elf-pavlik> q+ to ask about https://www.w3.org/2016/08/namespaces/
14:13:50 <ericP> ... moving to dcterms vocabulary
14:13:55 <acoburn> ack next
14:13:56 <Zakim> elf-pavlik, you wanted to ask about https://www.w3.org/2016/08/namespaces/
14:14:42 <ericP> elf-pavlik: can we freely re-define in the future or is there some process?
14:15:14 <ericP> acoburn: before CR, we're free to re-defined. It gets more complicated after PR
14:15:19 <elf-pavlik> this is less relevant to this PR since we swap external vocabs
14:15:36 <ericP> q+ to say the Q post-CR is "would it change an implementation"
14:16:00 <ericP> pchampin: gut feeling: as long as we're backward-compatible, it shouldn't be a problem
14:16:11 <acoburn> ack next
14:16:11 <elf-pavlik> scribe+
14:16:12 <Zakim> ericP, you wanted to say the Q post-CR is "would it change an implementation"
14:16:19 <ericP> ... for now, until we have a CR, we have no constraints
14:16:37 <elf-pavlik> ericP: would it change an implementation is the rule post CR
14:16:54 <elf-pavlik> scribe-
14:16:58 <ryey> q+
14:17:02 <acoburn> ack next
14:17:30 <ericP> ryey: dcterms format has several interpretations, as stated in its own definition.
14:17:51 <ericP> ... mime-type is the preferred interpretation but would those other interpretations be a problem?
14:18:06 <ericP> acoburn: we should be restricting the value to be a mime-type
14:18:42 <ericP> ... while dcterms:format is broader, we narrow it here
14:18:56 <TallTed> q+
14:19:11 <ericP> ryey: do we have to say "mime-type" vs. "media-type"
14:19:35 <acoburn> ack next
14:19:54 <ericP> TallTed: media-type is the appropriate term; can expand it to "mime media-type"
14:20:06 <ericP> ryey: agreed
14:20:15 <acoburn> PROPOSAL: Merge the PR replacing AS terms with DCTerms/LWS equivalents at https://github.com/w3c/lws-protocol/pull/219
14:20:16 <gb> https://github.com/w3c/lws-protocol/pull/219 -> PR 219 Replace Activity Streams vocabulary terms with dcterms and LWS equivalents (by acoburn) [vocabulary] [container]
14:20:16 <elf-pavlik> +1
14:20:24 <ericP> +1
14:20:25 <TallTed> +1
14:20:26 <acoburn> +1
14:20:27 <eBremer> +1
14:20:28 <pchampin> +1
14:20:30 <ryey> +1
14:20:30 <gibsonf1> +1
14:20:45 <acoburn> RESOLVED: Merge the PR replacing AS terms with DCTerms/LWS equivalents at https://github.com/w3c/lws-protocol/pull/219
14:20:57 <acoburn> zakim, open agendum 6
14:20:57 <Zakim> agendum 6 -- Vote: Remove the Slug Header requirements -> PR#224 https://github.com/w3c/lws-protocol/pull/224 -- taken up [from agendabot]
14:21:20 <ericP> acoburn: this is about the `slug:` header
14:21:54 <elf-pavlik> q+ to mention related issues from Samu in https://github.com/lws-contrib/lws-test-suite/issues
14:22:00 <acoburn> ack next
14:22:01 <Zakim> elf-pavlik, you wanted to mention related issues from Samu in https://github.com/lws-contrib/lws-test-suite/issues
14:22:05 <ericP> ... we were referencing the slug header text in RFC9110 but we weren't changing it at all
14:22:36 <ericP> elf-pavlik: samu noticed that the test suite makes some assumptions about the slug:
14:22:45 <ericP> ... we'll have to update the test suite
14:23:25 <ericP> acoburn: a server may ignore the slug. the Location: header is the authoritative response
14:23:45 <acoburn> PROPOSAL: Merge the PR removing Slug header requirements at https://github.com/w3c/lws-protocol/pull/224
14:23:46 <ericP> +1
14:23:46 <gb> https://github.com/w3c/lws-protocol/pull/224 -> PR 224 fix: remove Slug header mentions from LWS protocol text (by laurensdeb)
14:23:48 <elf-pavlik> +m
14:23:52 <gibsonf1> +1
14:23:54 <acoburn> +1
14:23:54 <eBremer> +1
14:23:54 <TallTed> +1
14:24:00 <elf-pavlik> s/+m/+1/
14:24:02 <pchampin> +0
14:24:06 <ryey> +1
14:24:25 <acoburn> RESOLVED: Merge the PR removing Slug header requirements at https://github.com/w3c/lws-protocol/pull/224
14:24:33 <acoburn> zakim, open agendum 7
14:24:33 <Zakim> agendum 7 -- Vote: Add subject_uri_schemes_supported to AS metadata -> PR#227 https://github.com/w3c/lws-protocol/pull/227 -- taken up [from agendabot]
14:25:30 <ericP> acoburn: when a client is interacting with the auth server, the client doesn't know if a particular schema is supported for subject URIs
14:26:31 <ericP> ... in auth server metadata, we have supported types (e.g. SAML SIDS), but it doesn't tell you how to deref those URIs\
14:27:02 <elf-pavlik> q+ to ask about scheme+method nuance in DIDs
14:27:03 <ericP> ... so e.g. a URI might not deref DIDs
14:27:32 <ericP> ... this is optional because you might have pre-existing trust relationships, such as the common case in SAML tokens
14:27:52 <acoburn> ack next
14:27:53 <Zakim> elf-pavlik, you wanted to ask about scheme+method nuance in DIDs
14:28:00 <ericP> ... if omitted, the default value is an array that includes HTTPS:
14:28:16 <ericP> elf-pavlik: in addition to scheme, do we need a method?
14:28:18 <pchampin> good point
14:28:36 <ericP> acoburn: yeah, these examples include both scheme and method
14:28:59 <ericP> ... that would be a good follow-up
14:29:09 <gibsonf1> gibsonf1 has joined #lws
14:29:15 <ericP> ... amend the PR or will we deal with it later?
14:29:22 <ericP> elf-pavlik: up to you
14:29:47 <TallTed> q+
14:30:07 <acoburn> ack next
14:30:43 <ericP> TallTed: not a blocker, but both of those definitions should have a dfn class.
14:30:54 <ericP> ... added to PR this AM
14:31:10 <ericP> acoburn: I can add that to this PR or we can come back to it.
14:31:21 <rbreitman> rbreitman has joined #lws
14:32:13 <acoburn> PROPOSAL: Merge the subject_uri_schemes_supported PR at https://github.com/w3c/lws-protocol/pull/227, with the inclusion of dfn tags and, for DID URIs, include scheme+method
14:32:14 <gb> https://github.com/w3c/lws-protocol/pull/227 -> PR 227 Add subject_uri_schemes_supported property to AS Metadata (by acoburn) [authorization] [authentication]
14:32:14 <elf-pavlik> +1
14:32:17 <ericP> ... amending the proposed vote with the changes from TallTed and elf-pavlik
14:32:19 <gibsonf1> +1
14:32:20 <ericP> +1
14:32:24 <eBremer> +1
14:32:28 <acoburn> +1
14:32:44 <TallTed> +1
14:32:49 <ryey> +1
14:32:55 <pchampin> +1
14:33:08 <acoburn> RESOLVED: Merge the subject_uri_schemes_supported PR at https://github.com/w3c/lws-protocol/pull/227, with the inclusion of dfn tags and, for DID URIs, include scheme+method
14:33:17 <acoburn> zakim, open agendum 8
14:33:17 <Zakim> agendum 8 -- Vote: Clarify OAuth best practices -> PR#225 https://github.com/w3c/lws-protocol/pull/225 -- taken up [from agendabot]
14:33:39 <TallTed> q+
14:33:50 <acoburn> ack next
14:34:15 <ericP> acoburn: adding a line to clarify that "this is part of oauth so it uses oauth security section"
14:35:05 <acoburn> PROPOSAL: Merge the PR clarifying OAuth best practices at https://github.com/w3c/lws-protocol/pull/225
14:35:06 <gb> https://github.com/w3c/lws-protocol/pull/225 -> PR 225 Clarify why OAuth best practices are applicable to lws10-authn-ssi-cid (by uvdsl)
14:35:06 <elf-pavlik> +1
14:35:09 <acoburn> +1
14:35:10 <gibsonf1> +1
14:35:17 <TallTed> +1
14:35:22 <ryey> +1
14:35:24 <eBremer> +1
14:35:26 <pchampin> +1
14:35:31 <ericP> +1
14:35:41 <acoburn> RESOLVED: Merge the PR clarifying OAuth best practices at https://github.com/w3c/lws-protocol/pull/225
14:35:51 <acoburn> zakim, open agendum 9
14:35:51 <Zakim> agendum 9 -- Vote (maybe): Remove the ETag requirements -> PR#228 https://github.com/w3c/lws-protocol/pull/228 -- taken up [from agendabot]
14:36:06 <acoburn> ack next
14:36:41 <ericP> TallTed: looking at the RFC, ETag was not mention as part of concurrency
14:36:59 <ericP> acoburn: RFC9110
14:37:02 <acoburn> https://datatracker.ietf.org/doc/html/rfc9110#name-etag
14:37:18 <ericP> TallTed: yes, ETag isn't mentioned in Concurrency and visa versa
14:37:49 <ericP> acoburn: after i opened this PR, there was some pushback from a person working on a js framework that does local-first
14:37:53 <gibsonf1> +1 to eTag as a MUST
14:38:04 <ericP> ... they wanted ETag as a baseline for concurrency control
14:38:27 <ericP> ... this PR softed this to a SHOULD
14:38:43 <gibsonf1> q+
14:38:48 <acoburn> ack next
14:38:56 <ericP> ... I'm not asking the group: "should we keep ETags as a must?"
14:39:03 <TallTed> q+
14:39:15 <acoburn> ack next
14:39:23 <ericP> gibsonf1: +1 to MUST. fine if people want more
14:39:58 <ericP> TallTed: it's fine if ETags didn't meet someone's use case but ETags aren't a heavy lift
14:39:59 <pchampin> q+
14:40:32 <ericP> ... the Q is "what are we blocking by requiring ETag?"
14:40:34 <acoburn> ack next
14:40:44 <ericP> pchampin: big fan of ETags
14:40:44 <acoburn> q+
14:41:07 <TallTed> q+
14:41:21 <ericP> ... would be sad if we didn't make it a MUST but acknowledge that they interact strangely with e.g. conneg
14:41:51 <ericP> ... saw similar issues in Community Solid Server
14:42:08 <ericP> ... we could provide some guidelines to help implementors avoid traps
14:42:22 <acoburn> ack next
14:42:27 <ericP> ... so I sympathize with not requiring them
14:42:48 <ericP> acoburn: (as inrupt). we'll implement ETags and support a MUST
14:43:15 <acoburn> ack next
14:43:16 <ericP> ... i've also encountered those screw cases but like an implementors note doc
14:43:33 <ericP> ... so support ETags as a MUST
14:43:37 <gibsonf1> q+
14:43:47 <ericP> ... (having worked around them)
14:43:52 <pchampin> TallTed you are right, but it is easy to get that wrong for implementers
14:44:24 <ericP> TallTed: I'm surprised that there are bad interactions with conneg
14:44:29 <elf-pavlik> q+ to suggest test cases besides prose in some WG NOTE
14:44:31 <acoburn> ack next
14:44:39 <ericP> ... +1 to impl guide. not married to where it happens
14:45:29 <ericP> gibsonf1: authn is trickier than conneg. needed to embed auth level in the ETag
14:46:04 <ericP> acoburn: i gather we should not vote on this ETag PR because it would be voted down
14:46:40 <ericP> ... I'd like to make sure that the ETag requirements are consistent and open another PR to manage editorial changes
14:46:44 <gibsonf1> +1
14:46:59 <elf-pavlik> q?
14:47:07 <acoburn> ack next
14:47:08 <Zakim> elf-pavlik, you wanted to suggest test cases besides prose in some WG NOTE
14:47:55 <ericP> elf-pavlik: +1 to ETags, but we can already start a WG note with a section for ETags and capture edge cases in the test suite
14:48:11 <ericP> ... perhaps optional tests, but at least something devs can take advantage of
14:48:17 <acoburn> zakim, open agendum 10
14:48:17 <Zakim> agendum 10 -- Discussion: Decide on resolution for StorageResource definition -> issue#220 https://github.com/w3c/lws-protocol/pull/220 -- taken up [from agendabot]
14:49:23 <ericP> acoburn: [github is still spewing unicorns]
14:51:08 <ericP> ... we have terms like `lws:Resource`. Q is what to include in the JSON-LD @context
14:52:21 <ericP> ... option1: keep StorageResource and change the the description to say it's an lws:Resoufce
14:53:11 <ericP> ... option2: keep StorageResource and change Resource->StorageResource in terminology
14:53:48 <ericP> ... option3: change this to Resource in the JSON-LD
14:54:05 <ericP> ... inline with how we define Container
14:54:44 <ericP> ... option4: change the JSON-LD @context to be "LWSResource"
14:54:50 <pchampin> q+
14:54:56 <acoburn> ack next
14:55:00 <gibsonf1> +1 option 4
14:55:09 <ericP> pchampin: prefer option 3
14:55:34 <elf-pavlik> q+ to mention LWS context being @protected
14:56:06 <ericP> ... if Resource is too generic, propose: spell it "LWSResouce" in the JSON-LD but have it resolve to lws:Resource
14:56:40 <acoburn> ack next
14:56:41 <Zakim> elf-pavlik, you wanted to mention LWS context being @protected
14:56:49 <ericP> ... lws:LWSResource would be a bit strange
14:57:37 <ericP> elf-pavlik: are we taking into account the fact that the @context is protected?
14:58:10 <ericP> acoburn: JSON-LD 1.1 allows one to map terms within the context of a scope.
14:59:06 <ericP> ... we already do that in the scope of access policies
14:59:17 <elf-pavlik> I assume https://www.w3.org/TR/json-ld11/#scoped-contexts
14:59:52 <elf-pavlik> #226
14:59:53 <gb> https://github.com/w3c/lws-protocol/issues/226 -> #226
14:59:53 <ericP> acoburn: there's a PR to remove the SSI/DID document. can we un-publish something in TR?
15:00:34 <acoburn> rrsagent, make minutes
15:00:35 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/17-lws-minutes.html acoburn
15:00:43 <ericP> pchampin: can't remove from the Web but there are processes to e.g. mark it rescinded
15:01:04 <acoburn> rrsagent, make minutes
15:01:06 <RRSAgent> I have made the request to generate https://www.w3.org/2026/08/17-lws-minutes.html acoburn