Skip to content

Latest commit

 

History

History
126 lines (91 loc) · 8.51 KB

2024-02-21.md

File metadata and controls

126 lines (91 loc) · 8.51 KB
Raw

W3C Solid Community Group: Weekly

Present

Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • 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

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 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: #618

Solid Symposium 2024

  • RG: I shall be organizing the Real-Time Solid session at Solid Symposium 2024 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: #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: #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: #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: #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:

    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

w3c-cg/solid#18

  • VB: Let's follow-up next week.