As you all know, we’re currently publishing the specification drafts for the remoteStorage protocol as IETF Internet Drafts. Many thanks to @michielbdejong and @fkooman for all their efforts and having been editors for so many years!
Seeing as we just came up on the 10th version, and hence the 5th birthday of the IETF drafts (after having published in a W3C Community Group before then), and also seeing as recent versions incorporated either very small changes, or even no changes at all, I think it’s time to discuss when, where, and how we want to move towards RS becoming a standard.
There are of course pros and cons to the various options and standards bodies for publishing such a final specification, and the very question if it should be final, and/or if it should be extensible by add-on specs, or completely replaced by a new version later on. Also, as a grassroots movement, we’re not required to publish with any standards body whatsoever, of course.
The IETF route
The draft currently states that its intended status is a Proposed Standard. Here’s a good starting point for learning about the IETF standards process, and I can also highly recommend reading The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force, which I got linked to by @michielbdejong a while back, and after which I felt that I had a decent grasp on what exactly the IETF is and is not.
The benefits I see to the IETF route:
- RS is based almost entirely on IETF RFCs. The people in charge of giving feedback and deciding on its progress towards RFC (i.e. the IESG) are best equipped to give feedback on it and ask the hard questions imo.
- No influence, or even voting on it, by corporate stakeholders
- We already tick a lot of the boxes on their requirements list, i.e. multiple working implementations
- If the draft gets rejected, at least we have a better idea of where we stand and if it’s still worth publishing it with a standards body
The major drawback—and I don’t really see another one—is that we have to cede any and all control over the spec to the IESG, who can actually edit, add and remove anything they like. However, as we’re not going there with a half-baked idea, but something we actually use daily already, and have iterated on for 5 years, I think even if they do, it’s unlikely we’d end up with some FrankenStorage spec afterwards.
I had a nice, long chat about the spec, and especially about missing features, with @untitaker at FOSDEM recently. We both agreed that the partial/resumable upload topic is the one thing we wouldn’t want to miss in a final version of the spec. Other than that, I don’t see any big features people are still asking for in the current issue list: https://github.com/remotestorage/spec/issues/
Not withstanding a decision on where we should take RS next, I think after having published a spec with no changes last December, it’s time for anyone still missing features or having any issues with the spec as is, to document those, either on GitHub or here.
So, what do you all think? Is 2018 the year we finally propose RS as an Internet Standard? Or is it too early? Or should we go another route entirely?