[standards-jig] informational vs. standards-track
matt at jivesoftware.com
Tue Jul 29 22:56:35 UTC 2003
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
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.
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.
More information about the Standards