[Standards-JIG] What is a bad reason to reject a JEP?

Peter Saint-Andre stpeter at jabber.org
Thu Feb 9 17:48:42 UTC 2006

Hash: SHA1

Akito Nozaki wrote:
> Dear Standard List,
> I've been reading through some of the archive and I've been seeing some
> bad reasons to reject a JEP. Sometimes succeeding in convincing people
> that its a valid argument.

Do you mean bad reasons not to accept a proposal ("proto-JEP") as a JEP
with an official JEP number? All such proposals are announced on this
list and there is a directory of them here:


Over the past ~2 years the following proposals have not been accepted as

1. Stanza Acknowledgement

2. RDF vCards

3. Roster Item Checking

4. Roster Subscription Synchronization

5. Stanza Security

6. Simplified MUC

In that same period, about 45 proposals have been accepted for publication.

If you have problems with the Jabber Council's decisions with regard to
any of the foregoing proposals, your comments would be appreciated.

If you are able to generalize from the 6 rejected proposals to a
consistent pattern, feel free to do so.

> 1. Its too hard to implement this JEP in my code.
> I've seen people complaining about a JEP, because there code isn't setup
> to do this.

JEP-134 (Protocol Design Guidelines) states the principle of keeping
clients simple. We attempt to follow that principle as defined here:


AFAIK, no proposal has ever been rejected because a particular developer
was unable to implement it in the code for that project. If you have
evidence to the contrary, feel free to make the argument.

However, if a proposal is (consistent with Ian's comment) unnecessarily
difficult to implement *in general* then it will probably be rejected.
So far Jabber/XMPP developers have seen that as a good thing.

> 2. I can't find a free/payed library that implements the JEP.
> Lot of the latest or bleeding edge stuff will not have a library
> implementation.

I have not seen this argument either. Examples, please.

BTW, we also attempt to avoid dependencies on payware and especially on
patent-encumbered technologies. There are good reasons for this, given
the open-source heritage of Jabber/XMPP technologies.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060209/2ca0d521/attachment.bin>

More information about the Standards mailing list