[Standards] certification etc.

[Peter Saint-Andre]

New thread.

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
           http://www.xmpp.org/extensions/xep-0073.html

XEP-0117: Intermediate IM Protocol Suite
           http://www.xmpp.org/extensions/xep-0117.html

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 
start.

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 
and openfire).

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. :)

> Even 
> 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 
problems.

> 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 certification).

> 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:

http://dev.jabbim.cz/jdisk

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. :)

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070316/4417297d/smime-0001.bin