[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


-----BEGIN PGP SIGNED MESSAGE-----
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:

http://www.jabber.org/jeps/inbox/

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

1. Stanza Acknowledgement
   http://www.jabber.org/jeps/inbox/ack.html

2. RDF vCards
   http://www.jabber.org/jeps/inbox/rdfcard.html

3. Roster Item Checking
   http://www.jabber.org/jeps/inbox/rostercheck.html

4. Roster Subscription Synchronization
   http://www.jabber.org/jeps/inbox/rostersync.html

5. Stanza Security
   http://www.jabber.org/jeps/inbox/secure.html

6. Simplified MUC
   http://www.jabber.org/jeps/inbox/simplemuc.html

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:

http://www.jabber.org/jeps/jep-0134.html#simple

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

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

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

iD8DBQFD64B6NF1RSzyt3NURAlEZAJ4skuf53mXRIncuFNLHlGbVruM/DQCgjRA9
mHYf/KpDeSv1vIBksJ2XciM=
=Cr8E
-----END PGP SIGNATURE-----
-------------- 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