Michiel de Jong

We should definitely mention it, because there is an expectation that URLs might be case-insensitive. E.g. on github they partially are: * https://github.com/remotestorage/remotestorAge.js/blob/master/doc/contributing.rst works * https://github.com/remotestorage/remotestorage.js/blob/master/doc/contriButing.rst does not * domain...

> only being able to create, not overwrite then I would call it 'append' or 'create' permissions, and the term 'write' would still mean everything that `:rw` has but `:r`...

> Would you tend to allow arbitrary folder depths for the scope in this case? Hm, we restricted it to zero or one levels in https://tools.ietf.org/html/draft-dejong-remotestorage-12#section-9 so then you would...

right, sharing = read-only, collaboration = read/write

i think it could be done by adding 3 verbs, one to create a derived token (read or read/write) for one specific document or folder, one to delete it, and...

pushing to 05 since we have nobody in the community who would currently have time to work on this.

We can keep this ticket open for now, but I'm starting to think it's better to implement collaboration at a higher level, e.g. on top of rss. People can then...

@trokster you can choose to do that at the [data module](https://github.com/remotestorage/modules) level, certainly. But doesn't need to be mentioned in the spec. Leaving the topic of sharing out of scope...

(we = Paul Tran-Van and myself)

Maybe in 07 ;) In fact, I think this would live on top of remoteStorage spec, see the I-D mentioned in https://github.com/remotestorage/spec/issues/58#issuecomment-107031200