I agree that at some point we need to create a standard that is separate from the reference implementation. Once we have a working reference implementation, we should write and submit a draft to the IETF. Based on what I've read on the IETF site, you have to have a working implementation before a draft will even be considered as a proposed standard. I don't think it matters where we maintain our initial draft documentation. If we think that having a separate waveprotocol.org website will encourage greater participation and adoption, then that's the way to go.
-Tad On Nov 14, 2010, at 9:15 PM, Michael MacFadden <[email protected]> wrote: > All, > > During the Wave Summit we discussed several topics. The possible move > of the WAIB project to apache incubator has been covered elsewhere: > > http://groups.google.com/group/wave-protocol/browse_thread/thread/5363c635e8e950fc > > However, in relation to the move to apache, the question of the Wave > Protocol vs the implementation that is Wave In A Box was raised. > Typically apache projects are code oriented. Apache does not > typically act as a standards bodies. This is bit of a gray area > since new projects applications / utilities often include XML / SQL > schemas, APIs, and messaging formats that other entities would need to > adopt to work with those components. These could be considered pseudo > standards; however, they typically dicate how to use or integrate with > the tool in question. They aren't really defining a public standard > that everyone should adopt. > > When we were initially discussing the the move to Apache, we assumed > that both the protocol and the implementation would both transition to > apache. All content would then be migrate from waveprotocol.org to > the new apache project. However it was brought up that another option > would be to leave all items relating to protocol development on > waveprotocol.org; only the Wave in a Box project (code, docs, wiki, > etc) would move to apache. > > The gist being that WIAB becomes the reference implementation for the > protocol, but that the two may indeed be managed differently. > waveprotocol.org could become the public body responsible for working > on the protocol. Open discussion and changes to the protocol would > happen there. There would be a process for planning and approving > revisions to the protocol. Once a revision is published, the WIAB > project would then update its codebase to maintain compliance. > > A few benefits to this approach are: > > - It fosters discipline on managing the protocol. Developers can't > simply make de facto changes to the protocol just by modifying the > WIAB code. > - It is possible that those that theorize about the protocol and those > that develop the WIAB codebase might not be the same group of people > (right now their is obviously a large if not total overlap). > - It sets us up to move the protocol to a formal standards body later > on if we see fit. > - It gives the impression that we are drinking our own cool aid, > rather than running around with scissors. > > > I would like to open discussion on if this is what we want to do, or > if we want to manage this all in one spot. There are pros and cons to > each approach. > > Sincere Regards, > > Michael > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
