[Standards-JIG] What is a bad reason to reject a JEP?
stpeter at jabber.org
Thu Feb 9 17:48:42 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards