[standards-jig] Display options in roster was Hidding groups

Jean-Louis Seguineau /EXC/TEC jean-louis.seguineau at antepo.com
Sun Aug 4 04:17:09 UTC 2002

Well not all commercial company are alike :) Thank you for having made my
point Ian: to get jabber the attention it deserves and not lock people into
proprietary extensions or client features there is a need for base features
in the protocol that could be leveraged by all client implementation.
I don't see any big revenue making comming from the lack of a simple control
feature on the element that are present in your roster. Jabber is so
expendable that there are hundreds of way to build specific extensions that
will lock their user to your specific client. The drawback is that if all of
us start adding a miriad of extensions, some of them very close in feature,
clients are becomming incompatible and interoperability suffers ( After all,
isn't jabber supposed to bridge those discrepencies ?)
On the other hand there are a small number of simple features that the base
protocol lacks, and I feel the community could benifit from it. Among them,
we have this display options for the roster (sorry to bring that in, but
having a commercial installed base of jabber servers and clients, we have
had this request for some time now) We could go the extension road, this
would be easy. But I frankly think having this in the protocol will allow
end user to have a similar experience with different clients and choose
appropriately. The end users will make jabber a success, not the developpers
only. This is the ubiquitus adoption of jabber that will make it the killer
we want it to be. And if you review the comments and comparisons about IM
clients it appears that jabber client are not well perceived. IMHO there is
a wide gap between client features and user experience, i.e. the end user
uses easy and simple features over and over again (by the way this is a
characteristic of M$ IM client which makes it even more dangerous than its
widespread presence on every PC)

You appropriatly mention that this would not impact the existing client
implemtation either, as jabber allow to ignore anything that it does not
understand. In this particular case, adding some attribute in the roster
item or the group tags would certainly not translate into drastic processing
changes, but can bring a great usability improvement  for the entire

Submitting a JEP is certainly somthing I am prepared to do, but I first
would like to assess the interest of the community for this change.


----- Original Message -----
> Message: 1
> Date: Fri, 02 Aug 2002 10:42:42 -0700
> Subject: Re: [standards-jig] Display options in roster was Hidding groups
> in Jabber clients
> From: Iain Shigeoka <iain.shigeoka at messaginglogic.com>
> To: Jabber standards <standards-jig at jabber.org>
> Reply-To: standards-jig at jabber.org
> On 8/1/02 2:38 PM, "Jean-Louis Seguineau /EXC/TEC"
> <jean-louis.seguineau at antepo.com> wrote:
> > So it boils down to two simple questions:
> >
> > 1/ would the community benefit from having a way to specify display
> > for the roster components (items and groups)
> I certainly don't see any harm in defining a standard.  For those that can
> use it, it will obviously be beneficial.
> I'd imagine many clients will want to keep certain aspects of roster
> handling proprietary specifically because it locks you into a particular
> client implementation.  I don't know if the competitive aspects are
> important now but I suspect as server operators begin to generate income
> from client-based revenue streams (adware, profiling, etc) client side
> standards will probably be dropped in favor of proprietary behavior.
> This still doesn't preclude the existence and usefulness of a standard.
> with all Jabber protocol standards, they would be optional.
> > 2/ if found beneficial, would it be better implemented it in the core
> > protocole by amending the base jabber:iq:roster or through an extension
> > mecanism.
> It would probably be better in the core protocol but making that happen
> be more difficult than defining an extension.  I'd think that you'd have
> submit a jep for the entire roster standard (with this added optional
> behavior) if you modify the core.
> -iain

More information about the Standards mailing list