-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add meeting agenda 2024-02-21 (#624)
* Add meeting agenda 2024-02-21 * Update minutes 2024-02-21 * Apply suggestions from code review Co-authored-by: Sarven Capadisli <info@csarven.ca> * Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com> --------- Co-authored-by: Sarven Capadisli <info@csarven.ca> Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Loading branch information
3 people
authored
Feb 22, 2024
1 parent
0e572a8
commit cd6bfae
Showing
1 changed file
with
126 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,126 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-02-21T14:00:00Z | ||
| * Call: https://meet.jit.si/solid-cg | ||
| * Chat: https://matrix.to/#/#solid_specification:gitter.im | ||
| * Repository: https://github.com/solid/specification | ||
| * Status: Published | ||
|
|
||
|
|
||
| ## Present | ||
| * [Virginia Balseiro](https://virginiabalseiro.com/#me) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * [Sarven Capadisli](https://csarven.ca/#i) | ||
| * Aaron Coburn | ||
| * Hadrian Zbarcea | ||
| * Ted Thibodeau | ||
| * Grace Elcock | ||
| * Rahul Gupta | ||
|
|
||
| --- | ||
|
|
||
| ## Announcements | ||
|
|
||
| ### Meeting Guidelines | ||
| * [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). | ||
| * [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). | ||
| * No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. | ||
| * Join queue to talk. | ||
| * Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. | ||
|
|
||
| ### Participation and Code of Conduct | ||
| * [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/). | ||
| * [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) | ||
| * Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. | ||
| * If this is your first time, welcome! please introduce yourself. | ||
|
|
||
| ### Scribes | ||
| * Sarven Capadisli | ||
|
|
||
|
|
||
| ### Introductions | ||
| * name: text | ||
|
|
||
| ## Topics | ||
|
|
||
| ### Demo | ||
|
|
||
| * eP: Did proof of concept for Solid Notifications Protocol Streaming HTTP Channel. | ||
| * SC: Could [Streaming JSON-LD](https://www.w3.org/TR/json-ld11-streaming/) be of use? | ||
|
|
||
|
|
||
| ### Special Topic Meetings | ||
| URL: https://github.com/orgs/solid/projects/16/views/1 | ||
|
|
||
| * eP: A couple of us attended. | ||
| * VB: Add Notifications to 2024-03-05? Done. | ||
| * VB: Mention new items in chat so we can put them on the board. | ||
|
|
||
|
|
||
| ### Co-chairs Rotation Schedule | ||
| URL: https://github.com/solid/specification/discussions/618 | ||
|
|
||
|
|
||
| ### Solid Symposium 2024 | ||
|
|
||
| * RG: I shall be organizing the [Real-Time Solid session](https://cxres.inrupt.net/public/SoSy24/RealTimeSolid/) at [Solid Symposium 2024](https://events.vito.be/sosy2024) to be held 2-3 May 2024 in Leuven, Belgium. | ||
| * RG: Anyone interested in speaking on notifications-related issues or in putting up a poster on the topic, please get in touch with me. | ||
| * RG: If you know someone that would like to speak, they can contact me directly via this forum. All are invited. | ||
| * SC: Will give the keynote (in the morning). | ||
|
|
||
|
|
||
| ### Add security consideration for serving user-created files | ||
| URL: https://github.com/solid/specification/pull/598 | ||
|
|
||
| * VB: From last week: | ||
|
|
||
| > ACTION: eP to make PR with security threat use cases and capture one discussed in the PR | ||
| * VB: Updates? | ||
| * eP: https://github.com/solid/specification/pull/625 | ||
| * VB: Would anyone like to review? | ||
| * SC: A key question is: is this a work item? Reviewing is good, but if the group is committing to it as a work item, we should follow normal procedure. Good start for best practices; my only comments are what is the source, and what constitutes a best practice? For each of the points, it'd be good to have a source as to why the community/group who is claiming this is a good practice (as opposed to a decision by a particular implementation). | ||
| * eP: This would be a non-normative document. Implementations would allow configuration options for their cases. For security vulnerabilities, we should know about it and provide them. We could rename if BP is not most accurate. Most important to have it in one place. Information as best of our capability and to make informed choices. | ||
| * AC: In the OAuth world, there are people that implement OAuth based systems and may not be aware of all the details of security concerns that exist in that space. This kind of a document would help implementers. To SC's point on consensus, it'd be good to have this info available; ultimately it'd make Solid and implementers safer. | ||
| * eP: Only thing we need to be careful with is that counter-measures we provide do not conflict with normative specifications. We're not even suggesting willful violation. | ||
|
|
||
| ACTION: SC to put comments on PR. | ||
|
|
||
| ### Should Solid (storage) servers support "RDF documents" containing multiple subjects (or quads)? | ||
| URL: https://github.com/solid/specification/issues/610 | ||
| * VB: From last week: | ||
| > PROPOSAL: attach label and ping Maxime to resolve it | ||
| * VB: Update? | ||
| * SC: There's plenty of feedback. I initially suggested to label this and have Maxime respond. AFAIK the questions were addressed. There's no more to do on that issue unless there's more information coming up. We can leave it there until Maxime responds. This does not require any change in the spec unless Maxime (or others) consider the response is not adequate. | ||
| * eP: I'd suggest to close issue and reopen if need to. | ||
| * TT: Concerned by the title of the issue... Perhaps it should've been changed? I haven't seen a suggestion where a Solid served document should only contain a single subject. The issue in and itself seems confused about how the RDF world works, including the misunderstandings in the definitions in the initial comment. By all means, be gentle, but I think, close with no action. | ||
| * SC: Also lean towards closing it. Nudge Maxime to make it more specific. Agree there were a bunch of things that were misunderstood, makes new definitions as opposed to reusing existing. | ||
|
|
||
| ACTION: VB to close issue with a comment linking to 2024-02-21 minutes. | ||
|
|
||
|
|
||
| ### Fine tune wording of the requirement for including Content-Type in the response | ||
| URL: https://github.com/solid/specification/issues/565 | ||
|
|
||
| * eP: HTTP spec only has SHOULD and SP elevates to MUST. Discussion was about awkward terminology in the HTTP spec. | ||
| * SC: Need to jog my memory / revisit issue. What's the question? | ||
| * RG: Since `HEAD` is low resource intensive call, Wouter's argument is that you don't need to include `Content-Type`. | ||
| * VB: Let's revisit this next week. | ||
| * TT: What headers can `HEAD` omit? My understanding was same as `GET` without body. | ||
| * AC: My understanding in RFC 9110, generally yes, but there are few headers like `Content-Length` being one where a few can be omitted. I think `Content-Type` is one of those that can be omitted. | ||
| * RG: From [9110](https://www.rfc-editor.org/rfc/rfc9110#section-9.3.2): | ||
| > The server SHOULD send the same header fields in response to a `HEAD` request as it would have sent if the request method had been `GET`. However, a server MAY omit header fields for which a value is determined only while generating the content. For example, some servers buffer a dynamic response to `GET` until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to `GET` might contain `Content-Length` and `Vary` fields, for example, that are not generated within a `HEAD` response. These minor inconsistencies are considered preferable to generating and discarding the content for a `HEAD` request, since `HEAD` is usually requested for the sake of efficiency. | ||
| * SC: Determining resource type like multimedia, RDF source, or something else. If a server does not do that, client needs to do a `GET`. Do we want to force clients to do that? I would lean towards making sure the server can generate `Content-Type` for `HEAD`. Lowers total number of requests. | ||
| * AC: +1 (we want to encourage the use of `HEAD`). | ||
| * eP: Agree, for example when an application wants to display different icons. If resource is created in ways other than Solid Protocol. | ||
| * SC: This could be a best practice: server should always know what it is serving. | ||
| * eP: In practise, if I run CSS and drop a binary file, I can still request it over HTTP but Solid server wouldn't know, | ||
| * SC: I don't know if that's a good practice / what that can do to an application. | ||
| * eP: Would you require server does not serve resources it does not the content type of? | ||
| * SC: Protocol doesn't explain the use case you mention because it is technically out of scope. At least - there is an issue comment on this - server should know what it is serving, and not serve something by accident. | ||
|
|
||
|
|
||
| ### Meeting recording and publication | ||
| https://github.com/w3c-cg/solid/issues/18 | ||
|
|
||
| * VB: Let's follow-up next week. |