[standards-jig] informational vs. standards-track

Joe Hildebrand 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
draft soon)

-- 
Joe Hildebrand

 

> -----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
> 
> 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
> > 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 



More information about the Standards mailing list