Meeting minutes
<TallTed> present+
Introductions & Announcements
acoburn: there is no meeting next two weeks due to holiday. We'll be back in January
gibsonf1: about Type Index: how do we work on that?
acoburn: I personally start with a google doc that is sharable. Then invite others to take an early look of it. Then introduce more widely. Ask questions among the people during discussion. Then open PR, if the text is in good form.
Authentication & Authorization Proposals
acoburn: We talked about auth&authn in the last few weeks. We vote on it this week. If passes, we go to the next item.
… Any further questions before going to that?
<acoburn> PROPOSED: To approve w3c/lws-protocol#43 (LWS Authentication) as an authentication model for LWS
<gb> Pull Request 43 LWS Authentication (by acoburn)
<ericP> +1
<laurens> +1
<eBremer> +1
<acoburn> +1
<RazaN> =1
<RazaN> +1
<ryey> +1
<pchampin> +1
<gibsonf1> +1
<TallTed> +1
<bendm> +1
<jeswr> +1
RESOLUTION: To approve w3c/lws-protocol#43 (LWS Authentication) as an authentication model for LWS
<acoburn> PROPOSED: To approve w3c/lws-protocol#45 (LWS Authorization) as an authorization model for LWS
<gb> Pull Request 45 LWS Authorization (by acoburn)
<ericP> +1
<eBremer> +1
<jeswr> +1
<acoburn> +1
<laurens> +1
<RazaN> +1
<TallTed> +1
<pchampin> +1
<gibsonf1> +1
<bendm> +1
<ryey> +0.5
RESOLUTION: To approve w3c/lws-protocol#45 (LWS Authorization) as an authorization model for LWS
Storage Description Discussion
acoburn: We talked about this during F2F meeting, then here a few weeks ago. I tinkered around with the early draft.
… The questions is on the *subject*
<dmitriz> i think storage as subject makes more sense.
acoburn: You see the `id` here. Assume it's at the root. You dereference it returns the description. Should the id be the description? Or, should the id be the storage?
<gibsonf1> +1 as storage as subject
ericP: I prefer id be the storage
<Zakim> gibsonf, you wanted to ask what is the uri for the storage request
gibsonf1: what's the request?
acoburn: You do a GET of xxxxx
gibsonf1: Does that have to be that exact location between the storage and the description?
acoburn: No, it doesn't have to be hierarchical
… In the link header, there will be a storage description field linking to the description
pchampin: to the initial questions of acoburn: I don't have a strong preference, but slightly towards the storage as the id.
<laurens> +1 to storage as root
pchampin: having the storage description at the root may be more natural for RDF people. But because this is for storage description, maybe a JSON person may find it more natural to have the root as the id, because of the hierarchical nature of JSON; while RDF doesn't have to do this, and either is fine.
ericP: when you are writing the assertion, you are writing for the storage, rather than the storage description
acoburn: I'm fine with either way. But it seem the general consensus is the second option.
dmitriz: I agree. Most seems the same to me. The storage description is kept minimal, and everything else is reserved for other Links, e.g. storage capabilities.
<Zakim> gibsonf, you wanted to ask on root vs storage in general
dmitriz: In JSON-LD, you can set a default context, to keep compatibility
gibsonf1: I do a get to the root container, and that gets the storage?
… maybe we want a URI for the storage that is different from the URI of the root container?
<TallTed> analogous to volume and (first sub-)directory
acoburn: it will be a significant departure if we consider Solid
elf-pavlik: would storage ever act as a client, for example to send notifications?
acoburn: The storage won't be a client.
… You can append the key id to the URI
<dmitriz> to me, I don't think storage should ever act as the client
<dmitriz> if you want that, an explicit notion of a server (or a notification service) makes more sense
elf-pavlik: there may be issues if you expose some key from the description. maybe there was a point of that
CRUD & Metadata Proposal
acoburn: maybe let's postpone that? we can make a UC/issue for that, and discuss it if it becomes more concrete
<elf-pavlik> dmitriz, I think it's fair, I just think it is important to consider it and maybe document that storage can't act as a client
<dmitriz> @elf-pavlik definitely, yeah
<gb> @elf-pavlik
eBremer: This issue (agendum 4) has been there for some time. We received some comments.
… Second one is from elf-pavilik
elf-pavlik: It may not be very friendly with offline persons, not just CRDTs. Apps may want to create some resources, and link them together.
… I don't want to block it. But think it's worth making this explicit
dmitriz: If it's not burdensome, we should support offline-first
<pchampin> s|@elf|
eBremer: Let's close the PR, not meant completely solved. In the meantime, we create relevant further PRs (or issues?) for discussion, for moving further
<bendm> w3c/
<gb> Pull Request 37 Initial CRUD with proposed metadata handling (by ebremer)
eBremer: or do we need more time?
<ericP> PROPOSED: merge PR 37 from eBremer
<eBremer> +1
<ericP> +1
<elf-pavlik> +1 - as non member
<acoburn> +1
<dmitriz> +0 (would like more time to review)
<TallTed> +0.8
<gibsonf1> +0 (more time to review)
<bendm> +0 (but I don't mind reviewing the merged one)
<ryey> +0 (would like more time)
<AZ> +0
acoburn: it looks people are generally positive. Let's wait a while for reviewing. Please raise questions in the PR directly, rather than waiting.
<dmitriz> comment directly
<dmitriz> issues about PRs is too many inception levels :)
elf-pavlik: I have some personal questions, not for blocking any PRs. Does the WG prefer creating more PRs, or comment on existing ones?
eBremer: please comment on the PR directly
ericP: this is editor's draft, not public working draft yet
acoburn: we are still not yet a CR draft yet
dmitriz: is it for this PR specifically, or about PRs in general?
elf-pavlik: is there are additional questions, but don't want to block it, how do people do the commenting?
dmitriz: Good point. Fortunately github provides a button for converting a discussion to an issue, while keeping all the provenance.
<dmitriz> +1 about the 'nonblocking' comment convention
ericP: or are you implicitly proposing to move to a non-blocking nature of working?
elf-pavlik: I have some questions of client authentication, if time allowed
ericP: who wants to linger (?) around?
<ericP> adjourned