[Standards] certification etc.
stpeter at jabber.org
Fri Mar 16 19:16:10 UTC 2007
Rachel Blackman wrote:
> I know I've been shot down before over this, but I /still/ feel we need
> a certification process to get people in line;
You have not been shot down, at least not by me. I think it's a fine
idea, indeed a critically important idea. We had a lengthy discussion
about the dire need for certification at the "XMPP Summit" in Brussels a
few weeks ago. Conclusions were:
1. We will use the existing standards process (not some new document
series) to define the certification levels. In fact we already have some
documents along those lines:
XEP-0073: Basic IM Protocol Suite
XEP-0117: Intermediate IM Protocol Suite
We could have more such documents -- extended presence suite via update
to XEP-0119 (=PEP+payloads), media suite (file transfer, Jingle, etc.),
security suite. Etc. But maybe basic and intermediate is a good place to
2. We will stabilize the certification level for a given year 6 months
before the year starts. So "XMPP Basic 2008" will be defined in the
version of XEP-0073 approved by the XMPP Council no later than June 30
2007. "XMPP Intermediate 2009" will be defined by June 30 2008. Etc.
This gives developers lead time to become compliant.
3. To start, we will base our certification on self-reports from
developers on each product or project.
4. We will establish an online testing network to make the self-reports
more transparent. We should have the first two servers up soon (ejabberd
5. We will have pretty little icons you can slap all over your website
saying "XMPP Intermediate 2008 Compliant" or whatever. A new XMPP logo
is in the works for this purpose (among others).
> a server that wants
> certification in a given year may have to add PEP if they want to be
> able to say 'XMPP Server 2008 Certified' or whatever. A client that
> wants certification in a given year may have to add Jingle if they want
> to be able to say 'XMPP Media Client 2008 Certified' or whatever.
That's the idea. :)
> if we don't do certification, we need to sort out some of the growing
> incompatibilities; we already have clients who are adding their own
> mutant markup for sending images c2c embedded in messages, because we
> can't even seem to agree on a single c2c stream initiation system that
> would allow AIM-style 'direct connect' for sending images.
Please name names (I'm a firm believer in public shaming), start a
thread about each feature we need to work on, and let's solve these
> We have a
> ton of XEPs that people have written up as pie-in-the-sky ideas
I'm not opposed to pie-in-the-sky ideas in general, there are plenty of
people doing research about how they could use XMPP for interesting
stuff beyond IM (e.g., Collaborative Data Objects). But those are
experimental things that should not be confused with features that
mainline IM clients need to implement (thus the need for protocol suites
> and that
> have never been implemented due to lack of PEP.
Yes we need to fix that pronto. Summer of code projects for PEP support
in servers and clients might be good. AFAIK, Openfire implements PEP so
that should give people something to test against (if not, then it's
close). Support in ejabberd would help a lot too, since that's what we
run at jabber.org (one of the larger servers on the network).
> We now have -- I cannot
> stress this enough -- TWO MUTUALLY INCOMPATIBLE FILE TRANSFER PROTOCOLS.
Yes that is a BIG PROBLEM. Unfortunately file transfer that works all
the time depends on NAT traversal that works all the time, or on the
ability to send a file to your server and have it host the file via HTTP
as the netlab folks have done:
Personally I think the jdisk thing is pretty cool. Not sure if they do
it this way, but accept the file from the client, push it to webdav,
virus check it, return a URL to the sender, forward that to the
recipient, and voila HTTP does the rest. It doesn't do all the fancy
"send me a whole directory with thumbnails" stuff that Google's http-ft
does, and the server admin would need to regularly remove files (via
cron job), but it seems like a nice approach.
> Doesn't ANYONE else want to focus on those? Anyone? :)
I do. And it's a lot more productive than questioning fundamental design
decisions we made in 1999. If you don't like *those* then start your own
open messaging and presence technology. :)
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards