Skip to content

Latest commit

 

History

History
166 lines (131 loc) · 13.2 KB

2023-08-16.md

File metadata and controls

166 lines (131 loc) · 13.2 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

  • Wouter Termont

Introductions

  • name: text

Topics

Special Topic Meetings

URL: #555

  • SC: Please propose special topic meetings in chat or CG weekly call. We can update the announcement board.
  • SC: This seems the easiest way, just to contain the table of dates, without a huge discussion or touching the event calendar.
  • WT: Could we add the timeslot itself to the official agenda?
  • SC: In the discussion or in the calendar?
  • WT: Calendar
  • SC: It is there marked as tentative.
  • SC: However it is processed, we can add the dates to the discussion.
  • RG: Can we add #525 whenever we're not blocking something else? Because it will probably take a couple more sessions to progress.
  • SC: I think the topics should be dedicated. Start with proposing a new entry date. We cannot always try to squeeze in random topics.
  • RG: This week's meeting was cancelled, so I mean then we can take that to be for #525.
  • SC: Can I just ask you to pick a date in September, and coordinate in chat?
  • RG: Sure.

Repository Labels

URL: https://github.com/solid/specification/labels

  • SC: This has been coming for a number of years and has been changing. We can clean that up further, process it and organize to a point that is useful (might need another pass).
  • SC: ... sums up labels ...
  • SC: Topics include the ones we use, actively or note.
  • eP: Can we dive into it deeper when we discuss reorganizing repositories.
  • SC: Yes, I agree.
  • SC: I do want to mention, I copied some of these labels to other repos. There is a commandline tool that does that. If we can trim down to a core group that is useful, we can copy those.
  • SC: Status labels I borrowed from Social Web WG. Emphasis I want to give is that typically in these projects/communities the proposer puts something forward, a discussion follows, and if there is consensus there, we can close the issue. To move forward, the person that's looking over the issue can change the labels to indicate where in the process it is situated (e.g., waiting for comments, etc.). We've used that in some repos and should try to use it more actively. Not only to organise, but also to signal current state of discussion.

WIP Implementation Feedback

  • SC: Please share any implementation feedback or interest to implement. Links to products/projects and demos welcome.

Add access management lifecycle to scope

URL: solid/solid-wg-charter#46

  • SC: We agreed that the CG will push these decision and reach consensus on the WG charter proposal and assign it to PA Champin, so that he has acknowledgement about what's there. He is on vacation now until end of week, so I was going to propose this, even if it is no major change.
  • eP: I recall that PA was participating and he sees it as just clarifying the scope. I thought we assigned to him because SC was creating most pulls and would have to approve his own, but this PR was created by A Coburn.
  • SC: ...
  • SC: Any objection to merging?
  • SC: No objection.

ACTION: SC will merge and link.

Rename 'Server' to something more specific — 'Resource Server' or 'Storage Server' or ...

URL: #548

  • SC: First two are reasonable.
  • WT: On a slightly more general note: I started a document comparing the shared definitions of all current reports. Can we have that as an organic definition document to refer to? Will create a PR (where?).
  • SC: PR against what document?
  • WT: Either in the protocol document or separate document.
  • SC: Are you mapping the concepts, e.g., agent — agent
  • WT: I am mapping — looked all the TRs — if two are using "resource server", for example, what the definitions are, and if they are same or not. As a proposal to use the same definition.
  • eP: What's the format you have it in currently? Can you add it to an issue (#48)?
  • WT: I have in markdown so I can just do it.
  • SC: It seems like useful exercise / information so we can review it. I think it would be better not to have a central location to which all the specs are referring. This would be unusual. Solid Team was working on Solid glossary. A spec usually defines its own terms, like Resource Server. Later one can use SKOS to match concepts across documents. I don't think we should have a central document with all definitions.
  • WT: Maybe we can have defined a couple of main concepts. Instead having each spec redefining it.
  • SC: For some concepts, it is unclear whether a spec is defining them or reusing them.
  • SC: A discussion topic would be a good place to post that information, and tag the editors of the specs in question.
  • eP: For me it would be interesting to see which are actually product classes. Can you highlight those? Composing multiple product classes in a single implementation seems common. I think we still do not have a clear view on how that should be done.
  • SC: But this is a subtopic. Not sure if it necessarily resolves it.
  • WT: This was more concrete issue, I think current definition of Server is very broad. I don't think is wrong but for conformance class should use something like Resource Server. OAuth has a good definition of that term.
  • SC: ... realises the more general issue: #480
  • SC: Can we move this till after Wouter's proposal?
  • eP: I think Resource Server is a great example to start from. It's already used in a few reports, and we also use Solid Storage a lot. Solid Notifications is not directly dependent on the Solid spec, but we assume that solid storage will implement notifications resource server.

ACTION: WT posts in discussion

Return ETag headers on PUT requests

URL: CommunitySolidServer/CommunitySolidServer#632

  • SC: Let's have additional eyes/minds on this. Cases in which the ETag header can(not) be used in PUT and PATCH responses. Potentially introduce a requirement or add advisory in Solid Protocol.
  • SC: General issue is that CSS might want more input on how it should approach. I raise this here so that people can have a look, both at CSS and Solid Protocol, to possibly refine the spec.
  • WT: What is the added value for the Solid ecosystem, on top of the affordances already provided by HTTP?
  • SC: It's about whether the interpretation of the spec is correct. Is it within what the Solid protocol allows? Or is it required?
  • WT: Given that current solid spec doesn't require anything about it, it is implementation choice, what would be the advantage of mandating it by the spec?
  • SC: I thought ETag was required.
  • TBL: For the logic to work we need ETag to work. It provides conditional writes. (explains ETag...)
  • SC: Solid says it is a MUST. Clients can expect ETag.
  • TBL: Clients need to rely on it. Is this issue on whether it is also required on PUT (unless the ETag RFC already requires it)?
  • SC: Solid protocol does not distinguish between the method; it relies on the RFC. The question is what the behavior is on PUT and PATCH.
  • AC: I want to make sure that any decision we make is consistent with current HTTP spec and how current browsers work. ETags work on representations. If a server returns a 204, we do not want the browser to cache that. We also don't want it to conflict with HTTP; it is really focused on representations.
  • WT: Wanted to join AC on that about representations. What I meant earlier, what is not in the current protocol; for GET, ETag is clearly there. Same could go for PUT; based on representation, it can return an ETag.
  • eP: I want to ask about PATCH, since it used a different content type. Which representation would be returned?
  • SC: It depends on the representation type of the response; whether the payload has a non-empty content or content-location header, e.g., 201 or 200. It seems like PUT or PATCH responses could thus fall under this case. Is that interpretation correct? What are implementations and browsers currently doing?
  • SC: POST is, I think, not the case, but it is a bit special in Solid because of container treatment.
  • TBL: The ETag has to do with representation, not with the body of the response, but with the state of the resource. With a PUT, the state is the body of the request. In a PATCH, the state has changed, the client needs to be able to update its ETag. The logic is always: whenever a resource state changes, the ETag changes.
  • AC: Agreed. I just want to make sure what we do does not break how browsers currently behave.
  • TBL: Browsers typically don't use a PUT.
  • AC: I mean, what if we use JavaScript, that's going to use the browser's cache.
  • TBL: It would be useful to have an overview of what we expect browsers to do.
  • SC: Sounds like a moving target. Like CORS. There is so much to do. We have a panel around QA work; we really need people. For us to show interop, we need to put the work in, either in the CG or in the WG. That includes the browser behavior: if we have any problems with how the web platform works, we can actually raise those, e.g., to the WICG.
  • RG: I want you to read 8.8.3 of RFC9110

    The "ETag" field in a response provides the current entity tag for the selected representation, as determined at the conclusion of handling the request. An entity tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both.

  • SC: I think there is indeed a nuance with the strong and weak ETags. What we currently have in the spec is what we came up with, but it is not set in stone. If you have some time, please read through them to not repeat anything. If there is new material, that might warrant a change.
  • SC: Can anyone interested add to this issue please, and then it might inform more specificity in the Solid protocol, and how much variability we expect here.
  • TBL: The protocol must give guarantees. The Solid protocol gives guarantees about the state of the resource on the Web. The ETag protocol is the best way of doing so. If it breaks, than you can lose data. We have tests, so that data will still be safe.

Chat Client-Client spec new work item

URL: #553

  • TBL: Does anyone have an objection to the proposal?
  • SC: We are evaluating the proposal.
  • WT: My point is the one I'm making in topic below. IMO the CG and WG are not places to define domain specific interop specs.
  • SC: Why not?
  • WT: Please see discussion for next topic.
  • TBL: Client-Client specs have always been part of the design plans. We also have code in SolidOS. If they are not included in CG, we can still do it as part of Solid Project.
  • SC: It is worth reviewing the objections. My understanding is that it is within CG scope to have it as work item.
  • VB: +1
  • Hadrian: I think we should first look into the next topic (issue #554), because there Wouter seems to support client-client interoperability. I'm not sure how this matches what he is saying here.

General vs domain-specific interoperability

URL: #554

  • Hadrian: There is difference between applications and services. There is a difference between top-down and bottom-up work on standards. I would like to do more bottom-up. With respect to #553, I would point out that there are connections to notifications.