[standards-jig] JEP-0102

Peter Ronez prnz404 at yahoo.com
Wed Jul 2 17:02:23 UTC 2003

> Or do you fear that these experimental implementations will stay
> forever, even after the JEP gets advanced to draft status, and these
> preliminary implementations would make jabber unstable or inconsistent?

OK, I think some people are missing the point. It's great if people provided
feedback and implementations to the JEP writers and what not. However, the
current mindset of how people want the JEP process to work is not scalable, in
my opinion. 

Imagine if Jabber becomes wildly successful tomorrow (fingers crossed ;). If
that's the case, their would be an absolutely flurry of JEPs from companies and
people alike trying to get their say in what the protocol will look like next.
And so the Jabber.org people go to work, pump out the JEPs, a couple of vocal
client writers say "yeah we need this!" and then all of a sudden its part of
the standard. This is one of many scenarios. 

A more likely scenario is that Jabber.org wouldn't be able to keep up with
those kinds of demands, and I don't think they need to. Every extension to
Jabber does not need the seal of approval from Jabber.org. However, the larger
and core pieces of the Jabber framework out to be approved by them so that
there can be a consensus. 

Take the issue about Avatars. Even though the JEP has been removed and is not
likely to be recommended by the Jabber.org staff, it shouldn't stop client
developers from implementing the feature. The people in that position can
always come up with their own JEP and post it on their websites for other
client developers to interop.

In a way, I can see Jabber.org's JEPs as the top-tier of Jabber specifications.
If Jabber.org says you need to implement this feature in this way, then it
should behoove all developers to do it in that manner. However, a second and
third-tier organizations (popular clients) can have their own list of JEPs that
are perhaps not pertinent to everyone but nonetheless useful to other client

I just want to say that I do feel the pain of the client developers. I too am
working on a client, and yes, it does suck not to have everything laid out
perfectly for me. However, I need to strike a balance here. Yes, I may need to
use some JEPs that aren't finalized, but I'll probably try to use only the ones
that are stable and not likely to change much. I could be wrong and it could be
painful to upgrade my client code later, but I'm sure its easier than upgrading
the protocol ;)

The implementations should mirror the protocol, not the other way around.

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

More information about the Standards mailing list