[standards-jig] informational vs. standards-track
JHildebrand at jabber.com
Tue Jul 29 23:25:43 UTC 2003
I think it's useful to have a peer-review function for informational JEPs.
Mostly, this forces us to check to see if the documentation is complete and
accurate. There are times when I don't want to have a discussion about
something, since it's already deployed, but I want other people to know how
to interoperate with me. If the community finds holes, I can worry about my
upgrade path by updating the informational JEP, or I can work with the
community to come up with an alternate standards-track approach.
JEP 25 (HTTP polling) is a good example of this. We implemented this as a
quick solution here at Jabber, Inc., and documented the protocol so that
other clients had a shot at being able to connect. There was a security
issue, which we dealt with by a careful release strategy, and updated the
doc. There still needs to be a standards-track replacement to this, so that
we can have full community consensus on the approach. (aside: I've actually
been thinking about this recently, and hope to be able to put together a
> -----Original Message-----
> From: Matt Tucker [mailto:matt at jivesoftware.com]
> Sent: Tuesday, July 29, 2003 4:57 PM
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] informational vs. standards-track
> 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.
> 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
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards