[Standards] certification etc.
stpeter at jabber.org
Fri Mar 16 20:45:21 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.
> 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
> 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
>> 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:
>> 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.
> 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.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards