[standards-jig] informational vs. standards-track
rob at cataclysm.cx
Tue Jul 29 23:56:38 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?
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.
Just because a JEP is informational doesn't mean its been "blessed" by
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.
Further, I intend to document the internal jabberd2 protocols in exactly
the same way.
> 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.
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?
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards