[standards-jig] informational vs. standards-track

Joe Hildebrand JHildebrand at jabber.com
Wed Jul 30 21:56:28 UTC 2003


Matt Tucker wrote:
> And I'm tired of the "good old boy" network that seems 
> intrinsically resistant to any form of change.

/me hums the "Dukes of Hazzard" theme, and decides not to take this
personally.

I wasn't part of the "original" community, but I still manage to get some
stuff done.  I'd like to think it was because some of my ideas had some
technical merit, and didn't insult the people that had come before by
assuming that they were morons or they were out to get me.  I'd also like to
believe that the JSF is a meritocracy, where anyone can contribute, and the
good stuff rises to the top.

Once you contribute your first JEP, I expect it to be examined with the same
level of scrutiny we apply to everything else.

> >>  1) Are frustrated that there has been so little progress on some 
> >>important JEP's.
> > 
> > Then they should participate in the process, rather than expecting 
> > people to do all of their work for them.
> 
> Yes, I agree. But, I think the process needs to change to 
> make this easier. 

How much easier can it get?  You create an XML document, and send it to
StPeter.  If you're talking about getting stuff approved by the council
faster, that's fine, but the council (to this point) is not responsible for
writing JEPs.  Just making sure they are correct, complete, and relevant.
It's up to JEP authors to continue to make them better until they are "good
enough".

> Further, I'm not talking about the 
> perspective of people that are creating new protocols. Rather 
> it's the perspective of client developers that are consumers 
> of the protocols the JSF creates and producers.
>
> The major audience for JEP's is *NOT* other JEP writers, it's 
> people looking to implement JEP's. That is why it would be 
> very useful for us to further classify what is a standard, 
> give specific recommendations for what people should 
> implement, what JEP's are informal/informational, etc.

How is this not what you are asking for:
http://www.jabber.org/jeps/jeplist.php

I'm all for having another place on whatever web site you want that has a
list of standards-track JEPs that are in the Final state.  Not all
protocol-related web pages need to be on jabber.org, even.

> >>  2) Have had tons of confusion over what JEP's they should 
> implement 
> >>in their clients.
> 
> > They can start a standards-track JEP that does the same 
> thing, using 
> > the information JEP as inputs, if they desire.  Pick a new 
> namespace, and go.
> > 
> > I don't understand why that's so hard to understand.
> 
> Let me give you a specific example. JEP 49 (Private Storage) 
> is Informational/Active. JEP-0098 (Enhanced Private XML 
> Storage) is Standards Track/Experimental. JEP 98 is already 
> better than 49 and will hopefully continue to improve. 
> However, if I'm a client author looking at the list of JEPs 
> trying to pick one of the two to implement, how do I know 
> which one to pick? Because I am personally quite familiar 
> with the JEP process, I could make an informed decision. I'm 
> not sure that most developers looking at the list of JEP's 
> would be able to, however.

Well... Again, this doesn't seem hard for me to understand.  If they want to
use a server-side implementation that currently exists, they use 49.  If
they want to use something EXPERIMENTAL, and have a server implementation
that they know exists, then they can use 98, at their own risk.  From
http://www.jabber.org/jeps/jep-0098.html:

<blockquote>
WARNING: This JEP is Experimental. Implementation of the protocol described
herein is NOT RECOMMENDED except in an exploratory fashion (e.g., in a proof
of concept).
</blockquote>

Literate client writers should be able to tell that 98 isn't for them, for
now.


> It doesn't benefit developers to have two different JEP's 
> that do the same thing. Wouldn't it be nicer if there was one 
> JEP that the community agreed was "best" and that went 
> through some sort of revision process? 

Like... the JEP process?  Once 98 is in Final, 49 will be eventually
deprecated, and finally removed.

> Of course, that won't happen when there are legitimately 
> different possible approaches to solving a problem (such as 
> the different e2e specs). But, if it's just a matter of 
> someone hacking something together as an informational JEP 
> and then someone else having to come through and
>   make it standards track, that's what it would be nice to 
> have a better process around.
> 
>  > Then you need to give actual substantive feedback on JEPs, 
> and  > write some of your own, rather than BOGGING US DOWN 
> WITH YOUR  > NIT-PICKING.
> 
> Give me a break. There's plenty of room for both technical 
> work and also discussions for trying to figure out how that 
> technical work can be improved or disseminated more effectively.

Understood.  Sorry for the capslock.  I was just pointing out the irony of
your being upset that we don't move faster, but wanting to put more process
in place.

> There's been some good suggestions around changing the 
> language on the website a bit to make it clearer what the 
> difference is between a standards track JEP vs an 
> Informational one. Can we pick one of those suggestions and move on?

I think constructive suggestions for wording changes are always nice, but
when prioritized against everything else, might take a while.

-- 
Joe Hildebrand



More information about the Standards mailing list