[Standards] certification etc.

Rachel Blackman rcb at ceruleanstudios.com
Fri Mar 16 19:44:48 UTC 2007

> New thread.


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

True, I was mostly remembering when I went on this crusade actively  
last (2004) being shot down by people who said it was really unfair  
to client/server implementers to make them have to meet a new  
standard each year in order to be certified, and that it would punish  
people who adopted XEPs (then JEPs) early by forcing them to update  
to whatever the final specification was when the final was ready, or  
lose certification, or that it was unfair to 'hobby' clients to force  
them to keep up-to-date with advancing standards.

I won't name names, especially since it can all be readily found in  
the jdev list archives for the appropriate time, but hopefully  
opinions have changed somewhat and tempers have cooled. :)

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

As long as the XEPs are updated regularly, I agree.  I just think  
that the XEP process has an unfortunate tendency to get bogged down  
in sideline discussions and dragged out.  :)

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

This helps, although see above. ;)

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

I also think XMPP.com or whatever should have a nice 'client' and  
'server' download link page, linking you to anything that's been  
marked compliant for the year.  If you aren't compliant, you don't  
get a link.

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

I believe Coversant was examining ways to send images in messages.   
(JD?  Someone?)  I know I'm looking at options for in Astra.   
Ideally, I'd us to use the same thing, but if I don't, hey, I'll go  
with my own.  (Probably an 'img' element with a 'jhttp' protocol  
portion, referencing a file to be picked up over Google's Jingle- 
based HTTP-FT thing.)

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

Sure, pie-in-the-sky ideas are great, but I'd argue that we're at a  
point where for all practical purposes a MAJORITY of the XEPs are pie- 
in-the-sky ideas.  I'd be willing to bet you that less than 50% of  
the XEPs we have are ones that have any sort of wide adoption.  I'd  
even be willing to bet that less than 50% of the /mainstream- 
applicable/ XEPs (i.e. not ones for automation and suchnot) that we  
have are ones that have any sort of wide adoption.

>> We now have -- I cannot stress this enough -- TWO MUTUALLY  
> 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.

I actually think that (once the rest of it is documented better)  
Jingle's approach is probably the right one.  If for no other reason  
than that, well, I really think we need /one/ stream initiation  
system instead of two or three or whatever, and we need Jingle anyway  
for AV.  I just think that the transition from one to the other is  
going to be a pain, and doubly so if it isn't driven by a  
certification process that sort of forces the issue.

I mean, it's all well and good to say, 'well, we'll just trust the  
developers to do it on their own time.'  But so far...

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/

More information about the Standards mailing list