[Standards-JIG] What is a bad reason to reject a JEP?
anpluto at usa.net
Fri Feb 10 20:35:34 UTC 2006
>>>>>> 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.
> 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?
IETF group has a working group for each individual standard doc (RFC). I
think its good to say each JEP is like a RFC. But here we have one
mailing list to go to all JEP.
I agree that you would get more feed back if you keep it in one mailing
list and the process would probably be much faster.
>>> 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
> 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 disagree. If one person spent the time reading your spec and found
something to suggest on the spec, I don't think it should be ignored.
I think in many cases the complicated question gets ignored, because
there is no good answer at the moment or at all. And yes it might be
forgotten over time. On the other hand the easy to answer
question/suggestion are usually answered by everybody on the list.
Some good example would be people discussing Crypto on the list. Lot of
the case people will ignore very complex suggestion/comment. I would be
one of those people to ignore, because I don't work with enough Crypto
to give positive feed back.
>>> 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.
It doesn't even have to be a bug tracking system. A way to keep track of
open issue so it is not ignored.
>>> 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.
I agree that getting things done is important, but I don't think
ignoring any comment is a very good process.
>>>>>> 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...
> 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.
Okay, I agree some specification are very complex. Some example I can
give is FAX over RTP... Simple explanation would be FAX protocol wrapped
in a digital stream. Telecoms standard is by far the most complicated
standard I have come across. But this is only because telecoms standard
almost always stack protocols to keep compatibility with older stuff. I
would guess these standard body are heavily influenced by large company.
Telecom equipment = Expensive :P
> Jingle is not intended to be a replacement for SIP (which is what I
> understand from your comment "live up to").
By reading the JEPs introduction, it sounds like your trying to provide
a easier way for gateway to talk XMPP<->(other VOIP system). To me it
sound like its not here to replace SIP or other VOIP system.
I'll leave it at that in here and I will talk about it in the other
thread where these issue are being discussed.
More information about the Standards