Meeting minutes
Introductions and announcements
laurens: I don't think we have any newcomer. Any announcement?
… Reminder that next week, the meeting will be chaired by jesse
Action Items
laurens: the only open action is assigned to Hadrian, who is not there.
… Let's table this.
Continued clarification of requirements (from Notifications and Eventing )
Requirement: Notification and Eventing
laurens: this is related to the Solid Notification CG spec
… it is about to notification between users, and between services.
… It somewhat overlaps with Req 18 "Inter-user communication" which we discussed last week.
… What do others think?
jesse: it does look like a duplicate.
… There are two kinds of scenarios:
… I want to subscribe to someone else's resource on their pod, this would be "notification and eventing"
… The other is: I post something to my pod, then posts something to your inbox.
… We should distinguish the two.
laurens: agreed; I can even see a 3rd one that may be a special case of the other: notification of change in ACL
… let's keep them separate, then, but "Inter-user communication" should be clarified
<Zakim> gibsonf, you wanted to talk about inbox...
jesse: we actually already have a proposal for renaming "Inter-user communication"
gibsonf1: we discussed this last time; I believe that 18 is about the Inbox that we have now, while the other is about change notification.
… I concur that we should keep them separated.
laurens: if we clarify 14 (Notification and Eventing), then we go a long way
… The "Notification specification" aligns with 14.
… The "Inbox specification" is not really described in the Solid CG spec, but would be more aligned to 18.
jesse: I would say "Subscribing to resource changes (notification)"
<otherJackson> +1
<laurens> +1
<uvdsl> 0
<pchampin> +1
<gibsonf1> +1 to also include acess permissions not subscribed to
<ryey> +1
<bendm> 0
<eBremer> +1
<bartb> 0
laurens: I see support
Requirement: Data Versioning
laurens: as far as I'm aware, Data Versioning is not part of any input document listed in our charter.
<TallTed> is it not covered by WebDAV?
laurens: I'm curious to hear about the use-cases that people have in mind.
… TallTed: I'm not sure, it might indeed be covered by WebDAV.
jesse: I suggest that at most in the LWS we have metadata for last-changed,
… but we don't go into specifying how to retrieve previous versions.
<Zakim> gibsonf, you wanted to talk about versioning
jesse: I see the value, but this is for a separate spec.
gibsonf1: I agree with Jesse. This is valuable, but we would need to define the intricacies of how to retrieve previous versions.
<Zakim> ryey, you wanted to discuss potentially CRDT, and/or collaborative editing. But not enforcing it
ryey: I agree with that as well.
… CRDTs and the like would be a use-case for this kind of feature.
<uvdsl> Isn't there already versioning via memento (or something called similarly?) I recall some LDP implementation supporting something like that (I think it was Marmotta)
ryey: Some basice things should be there to avoid damaging the data in this context,
… but it does not have to be a full-fledged versioning feature.
pchampin: There is something called "Memento", as an HTTP extension to retrieve previous versions whenever supported.
… I generally agree that this is out-of-scope and should be a separate spec.
<eBremer>
pchampin: we could hint at other specifications.
otherJackson: I would support saying "servers MAY support memento", not require it.
… it should be discoverable if the server supports it, to avoid application to duplicate work by deploying their own version management system.
bartb: I think having something like a current version of latest version could be useful.
… Example with shring your current address or body weight; you don't necessarily want to lose the previous versions.
jesse: I would argue that there is a difference.
… The versioning we are talking about is a versioning of the document.
… If your application describes attributes of a person that change over time, this should be part of your data model.
… "This is the body weight of Jesse on the 28th"
laurens: "resource versioning" might be a better description
<Zakim> ryey, you wanted to say about metadata / aux file -- is it not in the requirements?
jesse: I will make that change
ryey: we mentioned metadata auxiliary files several times today, but I don't see this as a requirement.
… Have I missed anything?
laurens: I'm not sure that we have a requirement related to that.
jesse: metadata auxiliary resource is a solution rather than an requirement.
… a requirement would be "be able to describe the last-change date of the resource"
… the auxiliary resource is a way to implement it
ryey: fair enough
… I think that the notion should be mentioned somewhere if we use it regularly in the discussion
laurens: I'm not sure we have full coverage anyway, but PR are always welcome.
<Zakim> gibsonf, you wanted to ask - maybe its as simple as adding ?date=timestamp to a request url for a previous if it exists
gibsonf1: just a thought: a simple way to spec that would be to include a datestamp in the query string
… visible to anyone, usable by servers that implement it
laurens: this is already very concrete.
… Quick strawpoll on the "resource versioning" requirement: we would consider it as a MAY in general, but requiring some minimal metadata
<otherJackson> +1 for optional (may) with an endorsement for a specific api like momento. I disagree with Jesse (below). I think it should be in the core document
jesse: I would not even write a MAY in the core spec; we as a group may produce an additional spec
<uvdsl> +1 to otherJackson's stance
<gibsonf1> +1 to May in core document with some guidance
<laurens> 0
<jeswr> +0
<TallTed> -1
<pchampin> +1
<eBremer> 0
<bartb> +1
TallTed: I thought we had discussed some version of auditing earlier (23 and 24).
… I don't think the MAY is a viable option here. We should go for SHOULD, possibly MUST.
… Otherwise we can not achieve audit trail.
<ryey> 0
laurens: I'm not 100% sure you need "Resource versioning" is needed to achieve the others.
TallTed: in some situations, we may have to go to archives CDs or tapes instead of the dynamic disc.
laurens: this is a fair point, though I believe that depending on regulations, compliance with auditability may not always require "Resource versioning"
Requirement: Resumable Large Data Transfers
laurens: from a technology point of view, this seems like a complex requirement.
… This is not included in the input specifications we have.
… What use-cases do we see for this, beyond storing movies?
jesse: I see this as part of a separate document for Large file support, and make it optional for servers.
… Would also include some ways to move big files around without needing to upload them again.
ryey: Storing videos can be a big use-case for this.
… We met this limitations recently with Solid.
… Part of the question is also: how large is large?
eBremer: "how large is large" is also relevant for Jesse's proposal of a separate spec.
… What is considered large today might not be in the future.
… My use-case is about digital whole slide images (WSI) that can be several GB.
… I agree this should be a separate spec, as it is a moving target.
TallTed: the transfer concern should be looked at as a user telling a server to send a file to another server.
… It should be doable, and depends on where the large bandwidth is.
eBremer: I agree that it is another use-case.
… But in my use-case, the large file is on my machine, and I want to transfer it to the storage. It can take weeks.
otherJackson: If the server does not want to support large files, then it should limit the size of the file.
… If the concern for implementing these features is to force server to support large files, then we should provide the API for the server to signal their limitations.
jesse: I think the server-to-server use-case is different from user-to-server, and should be kept out of scope.
… There are solutions out there for this.
pchampin: I wanted to reflect on the how large is large question
… I don't believe it would force servers to accept arbitrarily large files.
… a file is large if the risk of failing during the upload is high enough
… which also depends on bandwidth, storage ...
… It depends on what is large for me, which is different from person to person.
… I think it is an important feature to ensure that servers are accessible enough.
laurens: I'm a bit wary of with this requirement: aren't we overstepping in IETF land?
<otherJackson> +1 I would say an endorsement of current standards (like range headers) in the core spec is the best.
<eBremer> +1
<uvdsl> 0
<gibsonf1> +1
laurens: Strawpoll: do we see this as a requirement on the LWS protocol
<jeswr> +0 as a MUST in core +1 on an optional document
<bartb> 0
<pchampin> +1 provided that we can sufficiently rely on an existing spec
<ryey> 0 for "must have"; but +1 for "suggested"
<laurens> +1
<bendm> +0
laurens: most responses positive or neutral so far
Requirement: Offline Access and Synchronization
jesse: my understanding is that it is a requirement to support CRDTs as part of the specification
… my view is that we should not
ryey: I agree with Jesse. CRDT themselves should not be part of the spec as a necessity.
<eBremer> +1 "I agree with Jesse. CRDT themselves should not be part of the spec as a necessity."
ryey: However, some mechanisms should exist in the protocol to allow CRDTs in an easy way.
… (as opposed to very weird ways)
otherJackson: can you explain what these weird ways are?
ryey: Soukai currently stores the CRDT history into your pod
jesse: this is similar to the discussion on versioning; we could store different versions of a given resource in a container.
… If your server has a CRDT API, it can serve the latest version via the LWS API,
<jeswr> -1
jesse: but LWS should not mandate the CRDT API.
<gibsonf1> -1
<eBremer> -1
<bendm> -1
<laurens> -1
<TallTed> speaking of concerns involving large resources! 2 intact versions of BigFile could overwrite storage, where changelogging might consumes only a few extra KB!
<bartb> -1
<ryey> -1
<otherJackson> -1 for a required +1 OPTIONAL endorsement of a CRDT api
<uvdsl> -1
<pchampin> -1
TallTed: holding multiple copies of a large document will be costly.
laurens: I see mostly -1s, so we can strike out this requirement
Requirement: Serialization Format
laurens: this one seems quite a no-brainer
jesse: I'm finding the wording confusing. Is it "we should conteng-negociate RDF"?
… My position is that we should support content-type headers.
… We should not mandate conneg for RDF content types in the core spec.
… To allow others to use the spec.
TallTed: I would like to MUST content-negotiation, but I would be ok with a should.
… We want to encourage people who do not use RDF to do so.
… Part of content-negotiation is "give me this if you have it", part of it is "give me this if you can convert to it".
<Zakim> ryey, you wanted to ask what is implied in content negotiation in RDF? also not exactly understand Jesse's comment just now
TallTed: There is no point in serving a JPEG file in RDF, but the resource describing its history might/should be in RDF.
ryey: I wonder what content-negotiation implies for RDF?
… Conversion across RDF formats, or more?
jesse: supporting content-type headers could be "I know this is text/turtle because that's how it was sent to me, but I don't know how to content-negotiate it"
… the former could be described in a separate document, which would not be required of all servers
… That gives room to define similar documents for other kinds of content-types (withing this group or another group).
TallTed: content-negotiation does not imply content translation.
… The client says "I want one of these formats", the server has complete control over what happens next.
… [describes multiple ways the server can behave]
pchampin: I'm a big fan of content negotiation, a few years ago i would have said this should be a must.
… but things can be tricky in a read-write environment (e.g. with PUT)
… so I would be in favor of a SHOULD
… I would like the content negotiation to be driven from the client.
… Apache has this feature, and this would be nice.
… The server doesn't have to take the burden.
laurens: jesse, could you maybe rephrase this requirement, mentioning content-negociation, to discuss it in 2 weeks