[Foundation] Draft JID list

Rahul Dave rahul at reno.cis.upenn.edu
Wed May 23 17:01:49 CDT 2001


I got this from you:
> 
> 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.
A procedure could be instituted like python does for SIGS..
This link may be of use:
http://www.python.org/sigs/coordinator.html
> 
> 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
> here.
> 
> All that JIGs do, is generate proposals, and propose them to eachother or
I feel there's not much point to just generate proposals, or JEEP's, unless
there is an implementation aspect. Reference implementations are wanted, I think.
The JIG ought to vote on whether a proposal is worth working on for the members
at large, if its a core protocol, or standards, or server thing, but this
is obviously not needed for clients or transports.
> 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.

I have to disagree here. I think formalization of SOAP over jabber protocol,
and even maybe issues of aligning jabber and SOAP headers, or defing SOAP
equivalents of standards for transport over http..we want to interop afterall
, right?.. are all important concerns. Ofcourse this may be better handled in
a standards JIG, but I think doing RPC, both synchronous and asynchronous over
jabber is a big topic by itself.

I have to agree with Iain that separating the Jabber standard from the 
jabber protocol is important. I think the jabber protocol..the streams, the
tcp, etc could be handled by the server or transports group. Let the jabber
standards group handle the standard namespaces, and middleware do
SOAP+XMLRPC over jabber, and jabber over SOAP/XMl-RPC. It might be argued that
part of this ought to be handled by standards, and that middleware be a sub-jig
which I think is a fine solution too. I dont think then that we need protocol,
just have transport and standards. Also things like jabber email would be
done by standards..this would be a very big JIG...

I'm not sure whats the best splitup. I think middleware group should be like
standards, but without burdening standards for IM with the concerns of 
those like me who are more
interested in a general xml bus....

Also, I think business and compliance are two sides of the same "branding"
coin, so should be together.
Rahul
> 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.
> 
> Infrastructure
> 	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.
> 
> Business
> 	This JIG would manage the business interests of the foundation.
> 	It would handle finance (donations, expendatures, etc), marketing,
> 	trademark management, legal issues, corporation stuff.
> 
> Security
> 	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 
> 	inspections.
> 
> 	This JIG should also document the protocol and maintain that
> 	documentation.
> 
> 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
> http://mailman.jabber.org/listinfo/members
> 




More information about the Members mailing list