[Foundation] motions

Craig Kaes CKaes at jabber.com
Thu Jun 12 10:02:58 CDT 2003

Jinc will be needing this functionality over the next year, particularly for
its wireless clients.


-----Original Message-----
From: Peter Saint-Andre [mailto:stpeter at jabber.org]
Sent: Wednesday, June 11, 2003 8:17 PM
To: members at jabber.org
Subject: [Foundation] motions

Today Dave Smith and I had a conversation about the importance of 
seeking and incorporating feedback from implementers of our protocols,
and of designing protocols that people actually want to implement. The
JSF does not exist to create protocols for the sake of protocols. A
beautiful protocol with no implementations is useless.

With that in mind, I'm wondering if we need to be more stringent about
initiating Last Calls. Right now a Council member proposes a Last Call
and some number or percentage of JSF members need to second the motion.
While this requires some level of support from active members of the
community, it doesn't include a "reality check" that the proposed
protocol will actually be implemented. To take an example (the example
that Dizzy brought up with me), I think we can ask some pointed 
questions about JEP-0013 (Flexible Offline Message Retrieval). Is this
something that end users are begging for? Do the coders among us plan
to implement this protocol? If not, why are we pushing it forward? (I
ask these questions as co-author of the JEP.) It's easy to get caught
up in designing protocols, but we want to make sure that we're making
protocols that people want to use.

I think it would be really useful for JSF members to vote +1 on a Last
Call motion only if they intend to implement the protocol (either in an
open-source project or in a commercial product). If the protocol needs
to be implemented in both a server and a client, I think it would be
best to require at least two server developers and at least three
client developers to say that they plan to implement the protocol 
before going to Last Call (same for components). For client-only 
protocols (e.g., XHTML IM), we might require five client developers to
say that they plan to implement.

Obviously this is a much more stringent requirement than 5% of JSF 
members voting +1 just because the JEP contains a pretty protocol. But
I think a reality check of this kind will help to ensure that JSF
protocols are really needed and wanted out there in the marketplace.

If this makes sense (and I think it does), I'd like to ask these hard
questions about JEP-0013 (it's always best to make your own proposal
the "guinea pig"):

1. Are there at least two server developers who will publicly state
   that they plan to implement "Flexible Offline Message Retrieval" 
   as defined in JEP-0013? I know that there are representatives of 
   the following server developers on this list:

   - jabberd project
   - Jabber, Inc.
   - Antepo
   - Jive Software
   - i3Connect
   - Tipic
   - maybe more (if they're not members, they *should* be)

   Do you guys need and want this protocol? Will you implement it in
   your servers?

2. Are there at least three client developers who will publicly state
   that they plan to implement JEP-0013 in their clients? I know we
   have plenty of client developers on this list. So how about it?
   Will we see support for this JEP in Exodus, Psi, Nitro, MyJabber,
   mov, Gabber, TipicIM or TipicME, etc.? (Assume that some servers 
   will implement it.)

Unless I get public commitments from people that they think this 
protocol is needed and will be implemented, I will probably retract
this JEP or make it informational. The Jabber specs are busy enough 
as it is, without adding protocols that no one will use.



Members mailing list
Members at jabber.org

More information about the Members mailing list