[standards-jig] Re: [Foundation] streamlining the JIGs

Thomas Muldowney temas at box5.net
Tue Feb 26 16:33:39 UTC 2002

Replies throughout....

----- Original Message -----
>From: "Iain Shigeoka" <iainshigeoka at yahoo.com>
To: "Jabber standards" <standards-jig at jabber.org>
Sent: Monday, February 25, 2002 11:50 PM
Subject: Re: [standards-jig] Re: [Foundation] streamlining the JIGs

> On 2/25/02 7:15 PM, "dave at dave.tj" <dave at dave.tj> wrote:
> > You may very well be right, for all I know, about the window of
> > opportunity not staying open forever.  However, none of our competing
> > protocols is advancing nearly as quickly as we are, so I think time is
> > on our side if we simply continue doing what we've been doing so far
> > (outrunning the competition).  If we start making drastic changes,
> > we may make more progress, or we may mess everything up.  I just don't
> > think it's worth taking the risk until we have much more to gain and
> > much less to lose (i.e., when we have more momentum).
> I agree there is definitely a danger in pushing for progress too fast.
> Before new JEPs reach final standard state we should have some requirement
> for implementations to be created and used to make sure they live up to
> their promise.

I think that one is in there?  If not it has been discussed before that the
JEPs should come with a reference implementation in order to be accepted
(Just made me think of patent issues and what not.  Might need to make this
clear that it's a public reference?).

> My read of the industry is a bit different though.  The primary movers in
> the space as I understand it are actually delayed because of political and
> business reasons.  For example, as part of their SEC merger agreement AOL
> required to create interoperability standards and follow them before they
> are allowed to advance AIM in many important areas (multimedia IM being
> most visible).  Once these restrictions are overcome, I would expect to
> a massive push by the industry to move forward.

This AOL is very tricky, and supposedly they have already done this by using
a small unknown partner, which I can only assume they will buy out once they
are released from their obligations.  They do not have to largely
interoperate.  That's just a note, I agree with the industry moving forward
part =)  We're getting behind in some of the more crucial areas such as XML
middleware, even in IM we lack major features.

> IM is now breaking into mainstream financial awareness which means
> money and other serious efforts will soon follow as well.  The Wall Street
> Journal just published an article on IM today.  From my little perspective
> on it, things seem to be converging rapidly in the IM space.  Our only
> advantage is that we are currently running in front of the wave.  But I
> think the pace is about to change and I'm not sure we're going to be able
> keep up.
> I understand your concern though and it seems I'm outvoted 2-1 on this
> anyone else want to chime in here?)  I'll work with whatever we decide.
> > BTW - If you'd spent a year leading a team and finally put together a
> > JEP, how'd you feel if the council decided not to approve the product
> > of your labor?  I know I'd feel as if I had wasted a year, and I'd
> > probably take out my frustration on some unfortunate guy, and that may
> > have adverse effects on Jabber's progress, since I'm one of several
> > thousand people actively attempting to advance Jabber, rather than one
> > of several hundred thousand (as in other IM systems).  Besides, the
> Yes.  Although we should hope this case would be extremely rare.  In fact
> the current setup is really the only way I can see this happening.
> Basically some group going off into their own corner working on things in
> isolation from standards-jig.  If you're working on the standards-jig
> you will be getting feedback from a lot of people, including council
> members.  We'd never let you get as far as a JEP without serious warnings
> that something is wrong.

I agree.  The more thorough process allows for better peer review and less
headaches down the line.  Plus if major weaknesses are uncovered I would
hope the sytem is modular enough to be able to create a new version.

> > council isn't going to notice many problems because _nobody_ is going
> > to notice them until _much_ later.  (There are a few curious "features"
> > of the current Jabber protocol that stem from fundamental decisions that
> > went the wrong way - I define the "wrong" way as the less flexible way.)
> Agreed.  This would especially be the danger in creating standards then
> implementing them which is essentially the new standards process (the old
> being build it into jabberd then write it up as a standard).  However I
> think the new standards process is the only practical way to proceed if
> we're to have the community at large shape future standards.  The
> requirement for accepted standards (not drafts but standards) to be
> implemented (we were discussing at least 2 independent implementations)
> tested in the real world should hopefully reduce the chance of major
> blunders.
> There is no foolproof way to do these things.  The question is should we
> with a looser or tighter process.  We've got 3 votes (2 for looser, 1 for
> tighter).  My primary concern is the fact that we've only got 3 votes on
> issue.  At this rate, you, Peter and myself should just become the
> gods (all mighty triumvirate) and arbitrarily pass things I guess.  :)
> on the rest of you, chime in!
> -iain

We've tried to have a loose camp in the past and we had to tighten it up,
things ran ok for a while.  We said, ok we can loosen it up again, things
slowed down.  Yet again we're looking to tighten up, and from my experience
with Jabber every time we tighten it up things run better.  It's not about
overhead or bureaucracy, it's about having a well defined process that
allows for us to streamline to the end goal.  I for one am with you Iain,
because it more closely reflects what I was suggesting way back during the
initial talks for forming the council, jigs, and other jsf measures.

The concerns about getting shot down are partially valid.  It happened to me
with Avatars, but I also think it would not have happened if we had a
process for the JEPs.  It was so loose, and there were no defined channels
for the council to communicate with the authors, or the authors to
communicate with the council, so councils that were covered, or not valid
were not discussed.  A clear path would have made it easier to submit and
work through the council.

Overall I'm in favor of Iain's proposal.  Sorry this is rambly, my head is
still buried in JS.


More information about the Standards mailing list