[standards-jig] informational vs. standards-track

Matt Tucker matt at jivesoftware.com
Wed Jul 30 00:38:47 UTC 2003


> No, an informational JEP simply says "here's how we did it". Its useful
> for interop that we have a central repository so that people can see how
> other people are doing things.

Right, but again you get to create a de-facto standard by writing and 
publishing an informational JEP. The distinction between "informational" 
and "standards-track" is pretty subtle at the moment and I think very 
few developers understand the difference.

I do think it's valid to document "here's how we did it", but it should 
be extremely clear that it's not a standard. To me, that means it can't 
be a JEP. Also, I think a valid question is -- what's the point of 
publishing something if it's not going to become a standard.

> Just because a JEP is informational doesn't mean its been "blessed" by
> the JSF.

I think it has the perception of being blessed at the moment. It's 
published on the JSF website, is listed with other JEP's, doesn't 
include any warnings, etc. The only difference is a tiny bit of text 
labelling the JEP as "informational" vs. "standards track". I can tell 
you for sure that most outside developers don't understand the distinction.

> An example - several servers support the old jabber:component:accept for
> hooking up components via TCP. It works and is widely understood and
> implemented, but I don't think that anyone would be silly enough to
> suggest it should be on the standards track. Something like this is
> perfect for an informational JEP - it is documented in a well known
> location, and anyone can use it.

If it's written up as a JEP many developers will simply implement it 
assuming it's some sort of standard. Now, if we named it a "Legacy 
Protocol Description" or something instead of a JEP, I think most people 
would "get it". It's really just a matter of presentation.

> Further, I intend to document the internal jabberd2 protocols in exactly
> the same way.

I think that's great but that it just shouldn't be called JEP's.

> Interesting you bring up the vacation JEP - I will be changing it to
> informational with the next revision. This is another nice example - its
> a feature that requires a protocol extension. Its not specific to any
> project, but is something that to work, needs to be implemented by both
> clients and servers. Where is the proper home for this, if not as a JEP?

If it's not good enough to be standards-track then it's not worth making 
it a JEP. However, I do think the attitude needs to shift a bit on what 
should be standards-track. At the moment, it's only things that are 
"core". I think there is a much broader range of JEP's that can be 
standards-track as long as we add classifications as I suggested in my 
previous email.

I think a good model is the Java Community Process (http://www.jcp.org). 
Language extensions are created as JSR's. Each JSR has a lifecycle and 
is also part of a group of technologies. Here are some example links to 
check out:

* List of JSR's by technology/classfication: http://www.jcp.org/en/jsr/tech

* List of JSR's by status:

That kind of system would be extremely useful for JEP's. Client and 
server authors could then figure out what they should implement much, 
much more easily.


More information about the Standards mailing list