we were asked by Mark Nottingham from ietf if we are “willing to consider substantial changes to the specification, even if it breaks your current implementations if there’s good reason”. i think we should say yes to this for the following reasons:
breaking existing implementations is not really the issue, we currently break clients every six months (they need to include support for a new spec each 6 months), and servers every “rolling” 18 months (they should at any time support 1 of the 3 newest versions, so all 2012.04 servers will break in december, all -00 servers will break in june 2014, etcetera).
what happened to OAuth was imho a shift from “for web” to “for enterprise”, making that spec less fit for its originally intended use cases. but i don’t think we have to fear anybody being interested in that in our case, so we should be pretty safe from that risk.
what happened to webdav was imho everybody and their mother wanting to add a feature, leading to some implementations supporting only a subset of the features. this is the reason we currently don’t support byte ranges, putting bearer tokens into the query string, long polling, etcetera. the fear is that sooner or later a server would claim to implement remoteStorage, while in reality it supports only some of the pages of the spec. i am afraid that it will be harder to keep such non-essential features out, but maybe we can then instead invest energy in implementing a good compliance tester, and crack down with zero tolerance on server implementations that have such missing features.
@raucao@nilclass@silverbucket@jan@galfert unless any of you have any objections (either “no” or “i still have questions about this”) before EOB today (i.e., when the bbq starts ), i’ll tell them ‘yes’. is that ok? I’ll also ping ggrin, fkooman and xMartin about it again.
Didn’t we say we wanted to respond to their questions first, and ask them what they have in mind already, so that we have a proper basis for a decision?
I don’t understand what you mean. The point is that we may not want to let go, if they already have a direction in mind that we all oppose. So we have to be clear on that question first. After letting go, it’s not even a question anymore.
ok, we can make that a condition. so then we’re saying that in principle we want the spec to go to ietf, unless they already have a direction in mind that all or some current contributors oppose.
I haven’t really dealt with the spec, yet, and I’m not familiar with the IETF, nor do I really understand the question of letting go or not. Unless you have a good reason to request my opinion and want to explain to me more I guess I have to abstain from voting. Especially as a quick decision seems to be needed.
True @xMartin has a point. It’s pretty sudden, and I don’t think I understand fully the implications. Also, I am wary of the idea of a bunch of people “theoretically deciding the future definition of remoteStorage & features” while leaving us (ok, mostly @nilclass), the actual implementors, to be the coding monkeys following their decisions.
Will there be actual help in terms of people becoming involved in the project? Or is this just “peer review” where they take a superficial (albeit educated) glance at the spec and define a list of changes that need to happen before they adopt it, leaving us to go back to the drawing board and re-write a bunch of stuff?
The IETF FAQ that @michielbdejong linked are a pretty good read for better understanding the implications. I’d suggest reading the whole page, if you want to get a more detailed picture.
it would still be an open discussion between whoever is interested in the spec, like it is now. we would still be the people who discuss it. the only thing that changes is i give up my de facto bdfl rights over it.
this means that @nilclass, François and @raucao might actually get /more/ influence on the spec contents just that the forum where you fight your fight moves from gh issues to the apps-discuss mailing list. there is no entrance barrier there, everybody will still be able to say “I want byte ranges”, and it will be harder for me to tell you no because more people will be watching.
i’m pretty scared of feature bloat myself, as a result of this move, but otoh, this is not the first time the ietf produces a spec they got it right for IP, TCP and HTTP, we might also just give them some credit
they also have, in a way, a moral authority to get involved in a spec which they think is important. they are the internet engineering task force, and although no standards body is perfect, it would also in a way be quite pedantic to refuse their request. and denying them that moral authority would also make them look bad, and not good for their credibility. after all, we (at least i) want the ietf to exist.
), i’ll tell them ‘yes’. is that ok? I’ll also ping ggrin, fkooman and xMartin about it again.
just that the forum where you fight your fight moves from gh issues to the apps-discuss mailing list. there is no entrance barrier there, everybody will still be able to say “I want byte ranges”, and it will be harder for me to tell you no because more people will be watching.
they got it right for IP, TCP and HTTP, we might also just give them some credit 