[Standards] certification etc.

[Peter Saint-Andre]

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

Well, I don't think that argument is a strong one. Especially given (at 
least) six months' lead time.

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

Focus focus focus.

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

Duly noted. :)

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

Yep, we haven't started using xmpp.com yet, though we do control it.

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

Well in-band images have their own issues (image spam anyone?). But if 
you receive them from known entities then I suppose there might be nice 
aspects to them.

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

I think we need to get better about advancing things to Draft and Final, 
perhaps culling things that are not adopted (XEP-0013 anyone?), and then 
presenting only the draft and final specs on a certain page, with 
experimental specs shown elsewhere and maybe a separate page for best 
practices and organizational stuff.

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

Sounds like a separate thread to me. :)

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

Yep.

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

I'm with ya.

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/f44d1cc4/smime.bin