[Standards] XMPP team activity
ralphm at ik.nu
Tue Sep 29 17:36:18 UTC 2015
On 2015-09-29 18:59, Holger Weiß wrote:
> * Ralph Meijer <ralphm at ik.nu> [2015-09-29 16:30]:
>> I don't believe the protocols themselves are the issue here.
>> Implementations are.
> I think the problem is with both. One of the main issues on the
> standardization side has been mentioned several times: There's way too
> much redundancy, which forces developers to either implement a given
> feature in multiple ways or to just live with the interop issues every
> XMPP user is aware of.
> And while this problem seems obvious and severe to me, I don't get the
> feeling the standardization community sees an urgent need to tackle
> these things. Quite the opposite, I've seen people state that they
> "don't see why we'd deprecate something that's in use simply because it
> doesn't work well with something else in use."¹ As if standardization
> was just about documenting multiple (possibly incompatible) ways of
> doing things, rather than agreeing on a single way with the goal of
> yielding interoperability.
Well, I think this is mostly caused by the different states a
specification can be in during their path though our standardization
process. You'll find that if you take away the specifications that are
marked 'experimental', things look a lot better. And sure, we have had,
currently have, and in the future will have multiple specifications for
arguably the same thing. This is because we've learned from experience.
Take for example Service Discovery (XEP-0030). This is roughly the third
attempt at defining a protocol to find out what a server or client
supports. Before it went Jabber Browsing (XEP-0011) and Agent
The same with MUC, Publish-Subscribe, and signaling of media streams.
Backwards compatibility is always a pain, I agree. But nevertheless,
this standardization process does *not* preclude multiple actors to
write servers, libraries and clients that work well together. It is just
that different people have different priorities, diverse timing
constraints and, well, money.
The standards process has always aimed to improve whatever building
block a particular proposal was conceived for. And this is about
designing for the future, while attempting to provide upgrade paths.
I strongly believe that having competing *Experimental* specifications
are a *good thing*. It helps getting towards a good design that has the
potential to go to Draft status and beyond. Note that going to the next
phase, Final, requires multiple different compatible implementations.
>> The XSF is surely a great place to facilitate such discussions, but is
>> not in a position to enforce convergence around certain applications.
> Why not? If all you're saying is that you have no formal power over
> implementors, then you're stating the obvious. But wouldn't you see it
> as a goal of the XSF to work towards a consistent standard and thereby
> convergence of implementations?
I state the obvious because it turns out it is *not* obvious to
everyone, as I know from experience. I think our goal includes working
towards consistent standards, and believe the XMPP Council is doing that
properly. Every now and then, people bring up the topic of Compliance
Suites to address the other part, and I still thing that is a good
approach towards the goal you mentioned. Beyond that, I don't know who'd
make the time and provide the money to achieve the convergence of
implementations. If someone would start a certification body, I'd be
happy to voice my support, but I don't think the XSF should be it.
More information about the Standards