[standards-jig] informational vs. standards-track

Iain Shigeoka iain at jivesoftware.com
Wed Jul 30 16:31:50 UTC 2003

On Tuesday, Jul 29, 2003, at 23:29 US/Pacific, David Waite wrote:

> Matt Tucker wrote:
>> 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.)

I completely agree. The lack of a working group that can design at the 
highest level how the low level protocols should work together is 
crippling to our standards development. Requirements definition, 
overall architecture, and concrete use cases are really needed for the 
core concerns:

data storage (e.g. iq:private-ish foundation for all future data 
protocols like profiles, etc)
file transfer

The crosscutting concerns (aspect oriented programming terminology) i 
see are:


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

Sounds very reasonable. I definitely think we need to separate these 
more clearly. someone mentioned IETF as an example of good standards 
system and I couldn't disagree more. I think their RFC system is 
totally breaking down and is extremely difficult to use for getting 
information about protocols because info and standards are mixed 
together, everything is given equal weight, they still use plain text 
in a world that has moved to rich text (the lack of diagrams is 
especially hurtful), and rather than version the same standard, they 
release new standards that supercede old ones (try to get the 
definitive documentation on the current format of internet email, and 
now try to figure out what was the current standard in 1985).

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

I agree.

> 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 ;-)

Yup. Either that or assign all of them numbers in different doc 
listings. For all it's shortcomings I actually like the IEEE method of 
doing major standards families with the first number, and child 
standards as dot numbers. For example, let's say pubsub was described 
in the standards family 3. The core pubsub protocol described in 3.1, 
the disco aspect of pubsub was in 3.10 (disco always would be described 
in the .10 standard since it crosscuts all core standards), auditing 
aspect of pubsub in 3.20 (auditing concerns always own the 20s), etc.

That way, even if you have no idea what the particular standard is, you 
can easily figure out what you need (I'm implementing pubsub, grab all 
3.* standards, or I'm implementing disco, grab all *.1* standards).

The numbering scheme fits into the IEEE standards model of an owning 
working group, (and possible) subgroups for core protocols (e.g. JSF 
standards) that Dave proposes above and I agree with as well.

heh, I guess I'm demonstrating I'm much more of an engineer than an 
artist preferring this rigid hierarchical scheme over the freeflowing 
JEP process we have now.


More information about the Standards mailing list