[standards-jig] informational vs. standards-track

Ulrich B. Staudinger chicago5 at gmx.de
Wed Jul 30 06:21:22 UTC 2003


Just for the scrolls, i'd always accept informational jeps, but maybe 
put them into a separate area of jsf's site, not to mix with real 
standard jeps.

The JSF site and xmppworld.com are the entry points to xmpp instant 
messaging and therefore should give users the possibility to exchange on 
(good saying) 'common ground'. This gives informational jeps some 
seriousness, too. :) And the jeps don't get lost, nothing is more 
frustrating than seeing a page years after one did something cool with 
exactly the same things, just because the two didn't know of each other 
- conservating really should be an issue.

regards,
ulrich

Robert Norris wrote:

>>Any joking aside, I think the current JEP process does need some
>>change.  I've read many comments recently from people that:
>>
>> 1) Are frustrated that there has been so little progress on some
>> important JEP's.
>>    
>>
>
>So hassle the authors. Or take it on and finish it yourself.
>
>  
>
>> 2) Have had tons of confusion over what JEP's they should implement
>> in their clients.
>>    
>>
>
>Implement whatever you like or need. Implement whatever everybody else
>is implementing.
>
>  
>
>>Having a bunch of informational JEP's that don't go through a real
>>approval/review process doesn't seem like it will help with those
>>issues. Let's imagine a hypothetical conversation about an
>>informational JEP:
>>
>>Tom: "Hey Joe, how about changing XYZ in your informational JEP ABC?
>>Without the change the protocol is broken for reason 123."
>>
>>Joe: "Neah. I already implemented stuff the way I described it in the
>>JEP and an informational JEP is just meant to document something that
>>was already done."
>>    
>>
>
>If Joe won't take constructive feedback about why his protocol is
>broken, then he's an idiot. I doubt this would happen, because most
>people take some pride in their work.
>
>And there is _nothing_ to stop Tom forking and making his own changes.
>This sort of thing happens all the time, and is rarely a bad thing.
>
>  
>
>>How can we resolve disputes like that when there is no process in
>>place?  To me, that's what the whole standards process is for.
>>    
>>
>
>How do you resolve disputes normally? Do you talk to the people involved
>and try to find common ground, or do you get a large hammer and beat
>them into submission?
>
>If something is broken, you can fix it yourself and tell everyone else
>about it so they start doing it your way instead. And if noone seems
>interested, then perhaps you're wrong about it being broken. Or perhaps
>its not important enough.
>
>  
>
>>All I'm advocating is for higher quality JEP's and that anything that
>>appears to be an official protocol from the JSF is actually that. I
>>actually think that more things should be standards-track then are
>>now.  So, anything that is an informational JEP now should certainly
>>qualify to become standards track if so desired.
>>    
>>
>
>Depends on what it means for something to be Standards Track. At the
>moment, its fuzzy. Perhaps thats the only issue in this whole debate -
>maybe we're just debating semantics.
>
>  
>
>>If people aren't happy with getting rid of informational JEP's then I
>>think there are other alternatives that should work too, such as:
>>
>> 1) List standards-track and informational JEP's completely
>> seperately.
>>    
>>
>
>Not unreasonable, though there is a drop-down box on the JEP page that
>lets you restrict your view to one or the other.
>
>  
>
>> 2) Include a prominent disclaimer at the top of each informational
>> JEP that it's not standards-track and what that might mean to people
>> looking to adopt it.
>>    
>>
>
>What does it mean, exactly?
>
>Rob.
>
>  
>


-- 
Ulrich B. Staudinger
http://www.die-horde.de
jid: uls at dtedu.net





More information about the Standards mailing list