[standards-jig] informational vs. standards-track

Matt Tucker matt at jivesoftware.com
Tue Jul 29 22:56:35 UTC 2003


Peter,

I definitely agree that having different classification of JEP's makes 
sense. There are "core" JEP's and then other JEP's that only a small 
subset of users might care about. However, I think the notion of an 
"informational" JEP is totally bogus. It basically gives someone the 
ability to create a de-facto standard without any sort of real review 
process by the JSF membership. This is obvious from the recent 
discussions to change an informational JEP for software version. If you 
can do that, what's the point of the whole JEP process?

I think every single JEP should be "standards track" in that it has to 
go through a review process and then be voted on. If it's accepted, it's 
now a "standard" that will then go through a maintenance process. If 
it's rejected, it gets erased. All current informational JEP's should be 
deleted and moved to a "documentation" area of the JSF website. We 
should also:

  1) Have a process to accept or reject new JEP proposals. To use your 
same example -- are vacation messages something that the JSF wants to 
standardize? If so, then it should be a JEP. If not, it shouldn't be a 
JEP at all, not even an "informational" one. The accept/deny process 
would basically be a form to fill out explaining why a new JEP is 
needed, what it's for, why an existing JEP doesn't meet the needs, etc. 
It might also have an early version of the JEP if one is available. 
There would be a vote and then the JEP would start off as experimental 
and go through a lifecycle until it's approved.

  2) Once a JEP is accepted, it should be classified. At the moment, we 
  probably only have core JEP's and non-core JEP's. However, let's say 
that XMPP really took off inside financial companies and they started 
doing all kinds of interesting extensions. In that case, there might be 
a classfication of JEP's for financial applications. We then use these 
groupings of JEP's to brand protocol extensions: "Extended XMPP 1.0" or 
"Jabber IM Basic 1.0" for a grouping of core JEP's, or "Financial 
Services XMPP 1.0" or whatever.

Regards,
Matt

Peter Saint-Andre wrote:

> You may have noticed that JEPs 107 and 108 are Informational, not
> Standards-Track. This was intentional. My strongly-held opinion is
> extensions such as these are great, but they do not belong in the
> standard protocol. Standards-Track JEPs should be foundational 
> protocols that we require for compliance, such as disco, pubsub, 
> and probably file transfer. It's great if you want to build cool
> things on top of pubsub (as JEPs 107 and 108 do) or if you've 
> thought of a nice protocol for vacation messages or roster maps
> (JEPs 109 and 110 -- not picking on them, I just published them 
> last night), but IMHO they should not be standards-track.
> 
> My rough and ready test is: if we're going to require a protocol 
> for compliance testing, it needs to be standards-track. Otherwise, 
> it should be informational. 
> 
> So I think all new JEPs should be informational unless the author can
> provide a strong justification for making it standards-track.
> 
> Thoughts?
> 
> Peter
> 




More information about the Standards mailing list