> I happened to be at the Jabber BOF, which since has turned out to be a > hot topic, at least judging from the discussions at the IESG plenary. > As far as I understood, the objectives of the Jabber community were, > that they mainly wanted a place for the protocol documentation to be > published, and needed some expert review and help in sorting out the > security services for the protocol. A simple misunderstanding: they are some of the motivations, but not the main ones. We "mainly" want to keep the protocol from fragmenting into disarray, diverging implementations, lack of agreeance, poorly implemented/upgraded security additions as they come along, just all around poor support for a multi-domain multi-use protocol, where that poor support can directly impact the effectiveness and usability of other parts of the network. > I didn't see an overwhealming desire to release the control for the > development of the protocol to the IETF, but I may have misinterpreted > things. I never got my chance at the mic to explain my viewpoint on this. The protocol is based on namespaces, and the JSF is primarily a forum where people create NEW namespaces, which is as separate from HTTP as is new content types served over it. There is very little activity in the JSF around the core protocol, nor has there been any "change control" asserted beyond independently updated software releases. The "core" protocol, that primarily documented best by the drafts, isn't controlled by anyone at this point, you could say the JSF is the closest, but it has not taken that role. Again, we're coming to the IETF because we *need* a strong and proven process for managing this important layer in the Jabber architecture. We're not giving up any control, we simply don't have it. > My perhaps a rather simplistic suggestion at the BOF was that the > Jabber community submit their protocol specifications to the IESG to > be published as Informational RFCs. After an addmittedly quick skim > through the I-Ds, in my opinion they seemed to describe a pretty > mature protocol which arguably works. And my understanding of the IETF > process has also been that the IESG does commit to a fairly thorough > review for even documents intended as Informational, i.e., give expert > review, possibly referring to relevant WGs in the process. Another angle on the same theme: it's not the documents or publications themselves that help force consensus and stabilize a growing-unwieldy network protocol, it's the process of involving all the interested parties in a WG to iron out issues from their varied perspectives and having control of the protocol exist in the hands of a recognized standards body. I didn't say it very clearly at the BOF, but the reason we weren't doing this two years ago was because we didn't care about the protocol (our focus has always been open interoperability and accessibility), and had the expectation that anything the IMPP could come up with would be a superset of what we had and we could migrate to it, after all the IMPP architecture descriptions were almost identical to Jabber. That didn't happen, there is no protocol with comparable characteristics, and now we're faced with the popularity of our own protocol and the implications of new quasi-implementations on the network when nobody has the ability to say or enforce anything. > Why is that? After all, the Informational RFC should work equally well > for the Jabber community, and would even allow them to retain control > for the development of the protocol. I understand the Internet Relay > Chat is in fact Informational, but that doesn't seem to have hampered > its adoption in the Internet. Funny that you should mention IRC, that's exactly what we're trying to avoid, a protocol full of problems and holes with only patchwork fixes and "get a better implementation" solutions to work around it's deficiencies, and numerous extensions that aren't exactly optimal :) Jer