Meeting minutes
<TallTed> acoburn -- I've been trying to prepare for this call, and struggling to understand what the votes are. There are not clear questions in either cited PR. I guess maybe the votes are on whether to merge them in their current state? But there would then need to be new issues for the multiple open questions in each.
<acoburn> TallTed the Storage Description vote is to determine the direction we, as a group, want to go. I.e. (1) Storage Description is a CID with storage as a subject
<acoburn> or (2) Storage Description is a CID with storage description as a subject or (3) Storage Description is not a CID
<acoburn> once we have consensus there, I'll adjust the PR as needed
<acoburn> For the HTTP Query method, it is about whether to merge the PR
<TallTed> acoburn -- I submit that in future, the agenda items should include such details as you have now provided here. I am obviously not prepared to vote on either of the above propositions, but perhaps sufficient other participants will be, to make a quorum-satisfying vote.
<acoburn> +1, will do
Introduction & Announcements
acoburn: Ted made good point about listing the actual test for the votes ahead of time
Vote: Storage Description Resource as CID PR#183
acoburn: vote not about merging PR in its current for but direction we want to go
… defining storage desc resource as a specialization of SID 1.0
where storage a specialization of the CID
… but the SD is a subject of the CID
… not the storage
<acoburn> PROPOSAL: Define Storage Description resources as a specialization of CID-1.0 with Storage as the subject of the CID
<elf-pavlik> +1
<acoburn> +1
<jeremycaine> +1
<eBremer> +1
<gibsonf1> +1
RESOLUTION: Define Storage Description resources as a specialization of CID-1.0 with Storage as the subject of the CID
<acoburn> PROPOSAL: Define Storage Description resources as a specialization of CID-1.0 with StorageDescription as the subject of the CID
acoburn: it looks like that passed. marking as resolved
<acoburn> -1 (per first resolution)
acoburn: 2nd one basically conflicts with the first one were the storage desc is the subject of the CID
<jeremycaine> -1
<elf-pavlik> -1
<gibsonf1> -1
<eBremer> -1
Vote: HTTP Query method for Type Index PR#179
acoburn: i will integrate this into the proposal
… query method for the type index
… replaces get and post with http method with query
eBremer: with RFC 10008 becoming a stable proposal now we can use QUERY HTTP method
… one concern from PAC was that it could be premature and we may need GET/POST as a follback
… I see rapid adoption and we should be fine
TallTed: as as QUERY may be adopted by software producers, upgrading software in place may take years to roll out
… I think the fallback is important
gibsonf1: since everyone to comply with LWS will need to build new software, I don't see need to have that fallback
<Zakim> elf-pavlik, you wanted to suggest waiting for demand for fallback
elf-pavlik: should prematurely drop a fall back. wait for implementations to request it
jeswr: I don't think we will encouter many issue with clients understanding QUERY
… most clients support any method name, the default semantics work for query
jeswr: I dont think we will run into many clients not able to handle QUERY as most client are able to issue QUERY now
… were seeing a lot of client libraries quickly implementing support
jeremycaine: i think what people are saying about QUERY is probably right.
… but people coming along might build on something like node and the potentially not quite able to support this
… then there the agent that talks to AWS client that interacts with the LWS server
… but maybe what Jesse is saying that its already ready
jeswr: jeremy covered it. i dont anticipate issues with building on this
gibsonf1: the http library we're using doesnt support queries we will have to add that into the library
… but adding GET and POST will make that alot more complicated
acoburn: once we start getting implementation feed back, i think that will be very informative
<elf-pavlik> having tests for it may support that feedback loop
acoburn: any other comments before we go to a vote
<acoburn> PROPOSAL: Adopt QUERY method for the type index as proposed in w3c/
<gb> Pull Request 179 Replace GET/POST with new HTTP QUERY RFC10008 (by ebremer) [link-index]
<elf-pavlik> +1
<gibsonf1> +1
<eBremer> +1
<jeremycaine> +1
<acoburn> +1
RESOLUTION: Adopt QUERY method for the type index as proposed in w3c/
<ericP> +1
Test suite & Implementation work
acoburn: hear from Samu and both Erics
<eBremer> s/shamoo/samu
samu: started writing .net implementation fo LWS
… working on low-level fuctionality
… i will be working on query as I get to it
… implemented range request handling stuff like that
… focusing on readability and idiomatic code
… been looking and learning the spec and discussing with Jesse
acoburn: we will love any feed back from any one as a implementer and ask question now or at a later meeting
<Zakim> elf-pavlik, you wanted to ask when common test suite be used by this C# impl. and jeswr's Sparq impl.
samu: i will do that thank you
elf-pavlik: i understand you are working on a sample implementation and the test suite but noticed that Jesse jas this Sparq project.
… how soon before you think there will be something that can be used by multiple implementations
samu: a month or two but difficult to commit a proper timeline
jeswr: sparq is complete gen AI. it does run against tests that have been written
… will contribute tests to repo that EricP has created
<Zakim> gibsonf, you wanted to ask about implementation issue
jeswr: Erich B has does something similar
gibsonf1: not sure if this handled, when a container and a data resource are the same URI
acoburn: in that case you would have a two link headers one about the data resource and the other for thew container aspect or something like that
gibsonf1: issue spec requiring an object of a certain format fore both container and resource from the server os what as array of those two objects. that is my question
acoburn: yoi will have a resource that is both of these things
<Zakim> ericP, you wanted to say I moved PR#145's lws10-test-suite to https://
ericP: I move PR#145 into LWS contrib/lws-test-suite
<gb> Issue 145 not found
ericP: wont stay there..just a plave where me and jesse can work on it
… will be moved to w3c organization at some point
<Zakim> elf-pavlik, you wanted to offer help with https://
acoburn: if you could close that pr if it is empty
elf-pavlik: there was docker instance which made it easier
… happy to offer to help people integrate in their dev setup
samu: authoring that part is mine and thank you
jeremycaine: maybe in lws-test: what is scope of the test suite.
… building a rust-based solid server there were things I couldnt do i had to move it to google cloud
… is the lws test suite going to cover every apsect of the spec for somebody using it
ericP: try to test every normative feature for w3c acceptance
jeremycaine: issues with TLS re-directs
ericP: cause you needed local server to do the local dances?
jeremycaine: yeah
acoburn: just focus on forth coming software that samu is working on
samu: i have exp with solid test conformance harness
… my aim to cover all MUSTS and I will def aim to do it and make it easy to run
… shouldn't be any issues with security re-directs
Threat Model work item PR#202
<ericP> w3c/
<gb> CLOSED Pull Request 145 test: create strawman test suite (by ericprud)
<acoburn> Threat model for LWS
elf-pavlik: using template created by one of the authors threat modeling guide
… this is how its structured.
… this is early starter something we can iterate on
… invite everyone to review it, we can create issue and follow up PR
<elf-pavlik> https://
elf-pavlik: dropped better version of diagram in the IRC
… I want to focus (related to jeremy) basic setup of the system that we model threat around
… focus to discuss if this is a good starting point
… a minimal set up with what we would work with
… create variance like C4, its very flexible
… can we agree within next week if this is a good starting point?
ryey: page is adopted from other and there may be some content from others
… if you se something not right, please let us know as it is likely at this point
gibsonf1: can we use same terminology for the components that Jeremy's been setting up
elf-pavlik: yes totally
… we should align and eventually the udnerlying model we use in the C4 model
acoburn: people please comment on this PR at least as a starting point
<Zakim> elf-pavlik, you wanted to give shout out for the LikeC4 open source project
acoburn: could affect LWS implementations
<elf-pavlik> sponsors/
elf-pavlik: divided work between myself and ryey
… good to support maintainers
… for open source tool we are using
jeremycaine: confirm the PR is a start and not locked in yet
acoburn: yes, next week to adopt basic structure
… this would be a starting point
acoburn: shout out to Pavlik and ryey for getting this together
Discuss: Introduction PR#158 & Diagrams PR#159 agendabot]
jeremycaine: we have the intro PR and the diagrams pull request
… intro pretty much there
… intro should not be detailed description and get to vite next week
… the diagrams still need a bit of work
… few things to resolve like Fred was saying resource manager should be LWS manager
… describing the system as a whole
… an outstanding point
… we do have a bit of contention that provider could be interannly provided or externally implemented
… still a few things to work out and another session on the PR
… intro good for next week
<Zakim> elf-pavlik, you wanted to propose special 1h meeting this week to work on diagrams together
elf-pavlik: one hour session to work on those diagrams together
… provide this feedback next two day to incorporate on one hour session
<ryey> +1 to consolidation
acoburn: mention on mailing list that would be great
jeremycaine: I could do thursday for the hour meeting
acoburn: reasonable to have vote on introduction next week
… check on outstanding questions on the diagrams
acoburn: got feedback on json ld context and i will digest some of that into the prs
<elf-pavlik> https://