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

Peter Saint-Andre stpeter at jabber.org
Fri Feb 10 00:57:33 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Akito Nozaki wrote:
> 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:
>>
>> http://www.jabber.org/jeps/inbox/
> 
> Not just rejects but change request to JEP. What I don't like seeing is
> when change request gets no comment and gets ignored.

First of all, we don't have "change requests" like Liberty Alliance or
some highly formal standards development organization like that, we have
discussion lists. The JSF works in a way that is very similar to how the
IETF works. Have you participated in any IETF working groups?

> 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
> answered.

Or given time people who are really busy will get around to replying. Or
maybe the comment was not all that interesting to people in the first
place and they moved on.

> I for one 

And who are you? Are you a developer (which project or company?), a
standards geek, just someone who likes to read protocol specifications?
I'm trying to understand your perspective. What standards development
organizations do you think are ideal? Which ones are you familiar with?
Have you ever worked inside those organizations? Have you written any
specifications or are you only a consumer of them?

> would like more organization on JEP publishing and
> commenting... 

More process means more work. It's a tradeoff we've been trying to
balance since we started the JSF in 2001.

> something more organized then just the mailing list. It is
> almost impossible to keep track of open issues just with this list.

Yes, it's not easy. Imagine if you were the one writing 90% of the JEPs!
Then you'd really find it a challenge!

> Something simple as Bugzilla per JEP. At least then the open question
> can not go unanswered. 

Bug tracking systems can be ignored too. And the mailing list format
gets issues out in the open and enables people to discuss them. I have
found that bug tracking systems don't lend themselves to discussion.

> 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. 

All JEPs are tracked in CVS:

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/

There is a link to that page right here:

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

> Maybe I'm missing something but a simple diff
> of the 2 version of the doc might be good.

Feel free to contribute an XSLT for JEP diffs.

> Sorry went off topic but with the amount of JEPs that gets published, I
> believe that these things will become more important.

Again, it's a question of balance -- more process vs. getting things done.

>>>> 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
> 
> I think every protocol out there try to be simple... 

I don't think that's true. Or at least, they don't try very hard. Have
you read the Web Services specs or some of the ITU output? ASN.1
perhaps? Those specs are close to impenetrable.

>> 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...

I'd have to revisit that topic, it's been quite a while. The main S5B
author felt the suggested changes were quite unnecessary.

>> 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
>   +---> Jingle
> 
> 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
> the standard.

Jingle is not intended to be a replacement for SIP (which is what I
understand from your comment "live up to").

> How do we solve this... I don't know, but these are the things we are
> trying to solve by talking.

I am not yet convinced that there is a big problem to solve here. Or at
least the exact nature of the problem is not clear to me.

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

iD8DBQFD6+T9NF1RSzyt3NURAgh8AKChj+tg1W/GlZLkYACnAehP3JZ38ACg0FlR
PFMtjdqeYkw9RCFIj99kJHw=
=SVoF
-----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/6dfc4b8c/attachment.bin>


More information about the Standards mailing list