[Standards-JIG] What is a bad reason to reject a JEP?
anpluto at usa.net
Thu Feb 9 20:22:19 UTC 2006
Thanks for the reply.
>>> 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:
Not just rejects but change request to JEP. What I don't like seeing is
when change request gets no comment and gets ignored.
I understand that no comment or ignoring of post does not mean
rejection. Given time the person that wrote the original post will
forget and eventually the JEP might be accepted without these questions
I for one would like more organization on JEP publishing and
commenting... something more organized then just the mailing list. It is
almost impossible to keep track of open issues just with this list.
Something simple as Bugzilla per JEP. At least then the open question
can not go unanswered. Also another problem I have is changes made to
JEPs are very hidden, unless it is mentioned in the change log it is
hard to tell what changed. Maybe I'm missing something but a simple diff
of the 2 version of the doc might be good.
Sorry went off topic but with the amount of JEPs that gets published, I
believe that these things will become more important.
>>> 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:
I think every protocol out there try to be simple... If the method
people are using is too hard, people will suggest better ways that the
other author might have not thought about. This is why the list exist.
> 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.
The most interesting one that comes to mind is the S5B implementation
and extension for S5B (which is used by some client and backwards
compatible). Argument such as gain over complexity to me is not a very
good argument... specially at the time only few client had
implementation of such feature.
And again not very well documented so you have to dig through the
conference log and mailing list...
> 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.
If it is unnecessarily difficult, somebody or the person believe that
its unnecessarily difficult will come up with a better draft or jep.
Maybe a example would be...
TINS -> Zoep
Two ideas are currently being discussed, and again... complexity vs
feature is the main problem with the JEP. If Jingle can't live up to
SIP, and ends up becoming a standard. I can see the same thing happening
as S5B with extensions to Jingle, or a new implementation going against
How do we solve this... I don't know, but these are the things we are
trying to solve by talking.
>>> 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.
Sorry, my wording might have been bad here. I am specifically talking
about people requesting for a library on the list or asking for a good
suggestion for a library. Then complaining how the library is bad, and I
think this confuses people and I do not think it should be discussed on
this list. Some time these argument persuade people in different direction.
For example... Zoep and Jingle. I don't think a library issue should
ever be mentioned. It has nothing to do with the protocol and confuse
people that doesn't code. You are trying to implement protocol here, not
bring in library that exist.
I think a valid argument would be... "Does XMPP really need the complex
feature set SIP provides?" and go from here. Not because its complex and
hard to implement and SIP library sucks.
> 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.
I agree with pay ware/patented technologies being used. These would be a
valid argument not to use such protocol.
More information about the Standards