[Foundation] Draft JID list
colin at vedalabs.com
Wed May 23 16:58:13 CDT 2001
I agree with your ideas, but I also think that those are too many JIGs to
start with. I don't think more than three will be sustained by current
posters. I already have trouble with JDEV/DOCS/Mac-Dev/members/JAM lists :)
With temas integrating the web/news/maillists we should also re-evaluate the
current lists and merge some of them with the proposed JIGS (or would ALL of
I also agree with Iain that "protocol dev" would be better, at least now,
changed to "standards dev". Protocol specific items can be sub-JIGed if the
> -----Original Message-----
> From: Mathew Johnston [mailto:johnston at megaepic.com]
> Sent: Wednesday, May 23, 2001 4:33 PM
> To: members at jabber.org
> Subject: Re: [Foundation] Draft JID list
> Okay, I'm going to expand on what I suggested before...
> Practically, each JIG should have a mailing list, and
> probably a web site
> to publish it's products and keep people up to date on what's going on
> inside of the JIG. Each JIG does not have to manage it's own web site
> neccessarily, the job can probably be given to a publications JIG or
> something; however, each JIG should have a place to post
> files/pages without
> having to talk to any other JIG to do so. For this purpose
> maybe we can have
> one JIG manage the general websites, where each website will
> have a place
> where new files can be posted via a form, sort of like a
> message board -
> hell, this could even just be an archive of the mailing list
> or something.
> First, these are top level JIGs; each JIG can have more specialized
> groups of people inside of them, working on particular
> things. How a JIG
> breaks it's interests down is up to it really, but I'll
> suggest some things
> All that JIGs do, is generate proposals, and propose them to
> eachother or
> to the general membership for voting. Perhaps proposals MUST come from
> their respective JIGs to qualify for voting? Otherwise the
> membership may
> vote on protocol changes that they don't fully understand and have not
> been analyzed by the protocol GID - causing problems?
> I have not included a Systems/Middleware JIG because I don't
> think that
> one would produce much that actually effects the Jabber
> system it's self.
> If, however, it's found later that none of the JIG concepts
> listed here
> cover a particular topic that does effect Jabber or the Foundation, it
> could certainly be added later, with just as much ease as if
> it were here
> right now (in this list).
> JIG List:
> General/Foundation Organization
> This JIG will co-ordinate other JIGs by posting general
> news about
> the work that each JIG is doing. More communication
> means less chance
> of duplicated effort, or incompatable proposals being created.
> Each JIG should elect a representitive (or two) to make
> sure that
> the General JIG hears about what's going on inside of the JIG
> (without assuming that the general JIG knows anything
> specific about
> the informing JIG's area of expertise). For example,
> the General JIG
> should not be told anything that a general member may
> not understand
> without serious research.
> Also, this JIG should handle publication of other foundation
> related issues.
> This JIG would manage the jabber.org website and
> servers, as well
> as any other infrastructure relating to the foundation. This JIG
> would be responsible for managing mailing lists,
> keeping the jabber
> server on jabber.org running, managing the web site,
> etc. This JIG
> would likely request funds from the business JIG for
> server upgrades
> things like that.
> This JIG would manage the business interests of the foundation.
> It would handle finance (donations, expendatures, etc),
> trademark management, legal issues, corporation stuff.
> This JIG would concentrate on finding possible security problems
> in the Jabber protocol, and may also (if there is sufficient
> expertise) inspect server and client implementations
> for security
> problems. This JIG would likely propose protocol changes to the
> protocol development JIG and recommend default settings or
> implementation changes to client and server JIGs.
> Standards Compliance JIG
> This JIG would be responsible for evaluating products
> and issuing
> 'Jabber Compliant' label authorization for validating products.
> This JIG also decides what Jabber compliance actually is and
> makes sure that everyone else knows too (documentation).
> Protocol Development
> This JIG would be responsible for inspecting all protocol change
> proposals and even comming up with their own proposals
> for protocol
> changes. This should be the only party permitted to
> bring protocol
> change proposals infront of the general membership as
> this is the
> only party that would be known to be qualified to make such
> This JIG should also document the protocol and maintain that
> Server Interests
> This JIG should discuss server issues... propose new server
> related features or protocols to the protocol JIG. Developers
> may also try to come up with some definition of what a
> jabber server
> should hopefully support. Also, maybe try to define a common
> configuration file format so that servers can be
> interchanged, etc.
> Interest in new transports would also be discussed in this JIG
> Client Interests
> This JIG should discuss client issues... propose common client
> feature sets for different applications, or propose end user
> facilitating protocols to the protocol JIG.
> Interest in a middleware JIG has been expressed - this would
> probably exist as a sub-JIG of this client JIG.
> Is that a little clearer? If there are any major organizational
> divisions that I've missed, please speak up. :)
> Mathew Johnston
> Members mailing list
> Members at jabber.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Members