[standards-jig] informational vs. standards-track

Robert Norris rob at cataclysm.cx
Wed Jul 30 05:50:07 UTC 2003

> >People can create "de-facto standards" without ever drafting a JEP,
> >Matt. 
> No, that's simply not true. There must be a way to get others to adopt
> your protocol extensions. The only existing mechanism in our community
> for doing so is the JSF JEP processs.

It's not the only existing mechanism. Long before the JSF, the Jabber
protocol was being built by a loose group of developers writing code,
suggesting changes, watching those changes break, and trying again.
That's how a de-facto standard is established - a loose group of people
reaching rough consensus on how something should work.

> A "good" way to create a de-facto standard is through merit or
> popularity. When a de-facto standard happens for those reasons, at
> least it's not a bad thing in general. However, I think the current
> informational JEP process perverts those normal criteria. Simply by
> writing a JEP, however crappy it is, you have the ability to create
> your own de-facto standard since the document has been published by
> the JSF and will get viewed and implemented by the community since
> they will assume it's a "standard".

A JEP is just a document. It proposes a way of doing something. You're
free to ignore it. You can't create a standard. Something becomes a
standard when lots of people adopt it.

> >Selection of any given protocol as a standard is still left up to the
> >implementers -- those who choose to implement the JEP. A
> >standards-track JEP does not a standard make.
> >
> >What power does the JSF "membership" (such that it is) really
> >_have_?!  None. The Council holds final power over a protocol's
> >"approval" -- but even that doesn't mean much.
> I'm surprised that you believe that. I write an Open Source client
> library and generally only consider extensions to it that are JEP's. I
> think other developers mostly feel the same way -- they absolutely
> depend on the JSF to provide direction on what they should implement.

You choose to implement whatever you like. The only reason that people
look to the Council and their stamp is that they believe that the
Council have enough experience and objectivity to give the nod to things
that won't completely botch the protocol in the future.

You're free to ignore the Council - the protocol is there for anyone to
take and play with. People freely disagree with the Council all the time
(if you don't believe that, ask any current Council member - but be
prepared for the rant ;)

That intrigues me, actually - most people are happy to argue with the
Council until they're hoarse, yet will scream for more processes and
more control when their direction is taken away. Are there really that
many sheep here? Its kinda scary.

> >I view Peter's post as a question which drives at the very heart of
> >the value of the JSF membership. Are we here to act as a Community
> >that encourages and builds and collaborates (i.e.  running code and
> >rough consensus!), or are we here to be a standards-body that gets
> >into analysis paralysis?
> Nobody wants endless, pointless protocol debates. We all want rapid
> progress. But, a certain amount of process is a good thing. It
> provides a framework for collaborating on protocol dev and for
> resolving potential conflicts during that collaboration.

We have process already. And with it, we have endless debates. We have
lack of consensus. Why is more process going to make this any better?

Besides, the "framework for colloboration" is there - we have
standards-jig, we have conference rooms, we have whatever else. You can
pick up the phone and talk to other people. You can design the whole
thing by yourself. You can resolve conflicts by yourself. The JSF isn't
a government.

> >I don't know the answers, but I do know we need to ask the questions.
> >I also believe that we must reduce the amount of process, not
> >increase it.  We must get back to our roots of moving forward, and
> >away from these long-winded, often circular, protocol discussions.
> I hate process as much as the next developer, but everybody publishing
> JEP's with no approval process doesn't seem like good protocol design.

There is an approval process. Informational JEPs still start at
Experimental. They still have to go through a certain amount of review
before they go to Active. The author has to make sure that they are an
accurate reflection of reality.

For goodness sake, folks, you've got control of your own destiny here.
If you've got a good idea, implement the damn thing. Document it. Tell
other people about it. If it sucks, no-one will implement it. If its
good, everyone will implement it. I can see absolutely no reason that
this is a bad idea.



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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030730/9331e407/attachment.sig>

More information about the Standards mailing list