[standards-jig] Developmen Standards

Julian Missig julian at aspect.net
Tue Aug 14 18:00:59 UTC 2001

Well, I've been amassing a list of changes I/we need to the Jabber protocol this 
summer... but even our first JEP for resource handling hasn't really officially been 
approved yet, since there's no voting system. It's hard to move forward when none of 
my proposed changes become official... since the next step would be to get the 
changes into official documentation.

How is documentation going to be handled? Are we going to scrap the current docs, or 
what? Where in CVS should we be modifying documentation? Where should we be adding 

The current form of "here's this namespace, this is what it looks like" doesn't 
work, because there are little nuances with how things are handled. I'd be willing 
to make improvements, it's just very hard to tell which docs are being scraped and 
which are going to be kept current - even from a user's point of view.


---- Original Message ----
From:		temas
Date:		Tue 8/14/01 11:46
To:		standards-jig at jabber.org
Subject:	Re: [standards-jig] Developmen Standards

Most of it has seemed fine to me so far, I'm going to go back and read 
them all again today.  Overall it does seem rather quiet on the list....


Michael Bauer wrote:

>Yes!  A response.  Thank you temas.  I'm beginning to wonder if people had
>I would just add your caveats to this, temas.  These are really just
>guidelines.  I say things like "effort should be made across relevant"
>instead of "your product must for all" to keep things loose.  I think by
>addressing your concerns, like "of course, your products don't have to be
>open to work with open source", and "except for specialized applications
>that are integrated with an operating system" it'll make things clearer.
>I am a little concerned about feedback, here.  I thought I addressed
>everyone's concerns.  Is no one reading this list?
>-----Original Message-----
>From: temas [mailto:temas at box5.net]
>Sent: Monday, August 13, 2001 7:37 PM
>To: standards-jig at jabber.org
>Subject: Re: [standards-jig] Developmen Standards
>Well this one finally caught my eye, and I feel I need to stir the pot 
>here a little bit.  A few lines in here tickle me wrong.  I'll chop them 
>out below.
>Michael Bauer wrote:
>>The Development Standards describe what software development practices
>>should be followed in order to effectively integrate software within the
>>Jabber infrastructure.  Effectively integrating software centers around the
>>delivering software that substantially conforms to relevant protocols,
>>behaves appropriately within the overall Jabber environment, and is
>>developed in a spirit of mutual cooperation.
>"... developed in a spirit of mutual cooperation"
>I can understand why this sounds great, but if I was an outside company 
>it would sound to me that unless my product was open in some way than it 
>wasn't getting past this marker.  Jabber should be acceptable in all 
>scenarios as long as they conform to the protocol guidelines.
>>Software should conform to a set of Jabber protocols.  Submissions should
>>accompanied by a clear description of which draft, core, or alternative
>>protocols the software conforms to as defined by relevant namespaces.  
>>Whether included with a software submission or not, extensions to the
>>protocols should be described with a Jabber Enhancement Proposal (JEP -
>>http://foundation.jabber.org/jeps/) that's been submitted to the
>>Jabber Interest Group (JIG - http://foundation.jabber.org/jigs.html).  
>>Operational integrity of software is up to the individual developer or
>>company.  Effort should be made on the part of the developer to create
>>software that conforms across all relevant protocol categories and across
>>all operating environments.  Effort should be made on the part of the users
>"...and across all operating environments."
>This just seems like it's asking for trouble, and in reality seems 
>rather broad.  Personally, I'm a strong believer in specialized apps, 
>working in unison with their operating environment rather than some 
>abstraction layer.
>>to provide effective and constructive feedback to developers to help them
>>accomplish this goal in return for use of the software.  Software should
>>fail gracefully whenever possible.  Users should provide specific test
>>to identify software failures to assist developers in enhancing operational
>>Standards-JIG mailing list
>>Standards-JIG at jabber.org
>Not much, but wording is always key in docs like this.  Thoughts?
>Standards-JIG mailing list
>Standards-JIG at jabber.org
>Standards-JIG mailing list
>Standards-JIG at jabber.org

Standards-JIG mailing list
Standards-JIG at jabber.org

More information about the Standards mailing list