[standards-jig] informational vs. standards-track

David Waite mass at akuma.org
Wed Jul 30 06:29:06 UTC 2003

Matt Tucker wrote:

> 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 actually see the need for three categories:

- core standards: The things like pub-sub and disco which affect the way 
all future standards are written. I think with pub-sub and file transfer 
we've seen the disadvantage of having people just submit JEPs at their 
whim for these large problems - I still argue we need to form JIGs for 
these important things, even if something as informal as a sign-up 
sheet. We should also agree on the goals established by the JEP(s) 
produced to solve these core problems. Before a standard is pursued, the 
council should probably approve it, and we probably should add more 
process to these (such as at -least- gathering requirements before 
creating protocol proposals.)

- informational notes: Documentation of existing implementations, as 
today. The big difference is that 'existing' is enforced - if there 
aren't deployed systems using the methods described in the note, there 
is no reason to accept it.

- member notes: We should facilitate discussions among the membership 
for things which aren't neccessarily important enough to be considered 
'core', but which other groups may still be interested in. Mood is a 
great example - not all GUIs will even have a place for it, but there 
are still probably many people in the community with opinions and 
developers within the community who wouldn't mind adding such a feature. 
Think 'jabberstudio for protocol rather than software'. These are not 
standardized, not evaluated by the council (unless the authors want us 
to evaluate it or give advice; I consider myself as a council member to 
also be a resource)

> 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: 

I think they should be called informational notes rather than JEPs 
because the P stands for Proposal. Something which documents an 
existing, deployed system is most certainly not a proposal :-)

And while we are at it, I'd love it if only informational notes and JEPs 
which are made 'active' are assigned numbers, and before that they have 
an internet-draft document name and versioning. It would sure make it 
easier to figure out what people are talking about ;-)

-David Waite

More information about the Standards mailing list