[standards-jig] Constraining standards? (was: Discussion onJEP-0016: Server-Based Privacy Rules)

Shawn Wilton shawn at black9.net
Tue Jan 22 21:53:02 UTC 2002

I'm sorry, but there's no such thing as bloat by having too many unique

It still remains a simple concept, if you want to implement it, implement
it.  If you don't, then don't.  The point is that you *will* have the

The whole point of having standards are so people don't implement different
ways of doing the same thing.  It's called interoperability.  The wonderful
advantage of having a standard is that if I have to use two different
clients, one for windows, and another for unix then I can move from client
to cliient and use the same blacklist (for example).  Now I don't personally
have this problem since I use a Java client, but those that don't might
really like the idea of a synchronized blacklist so they don't have to
update everytime they swap clients.

-----Original Message-----
From: standards-jig-admin at jabber.org
[mailto:standards-jig-admin at jabber.org]On Behalf Of Iain Shigeoka
Sent: Tuesday, January 22, 2002 1:41 PM
To: Jabber standards
Subject: Re: [standards-jig] Constraining standards? (was: Discussion
onJEP-0016: Server-Based Privacy Rules)

On 1/22/02 10:42 AM, "Jacek Konieczny" <jajcus at bnet.pl> wrote:

> On Tue, Jan 22, 2002 at 09:33:43AM -0800, Iain Shigeoka wrote:
>> How Clients configure blocking should also be out of the spec.
> I cannot agree with you.
>>  It can be an
>> IQ extension but it should also be just as possible to support blocking
>> provide all configuration using a web page, or other existing tools.  I
>> don't see why it must be through a standard Jabber IQ protocol (or
>> it may be done).
> If it is not described in the standard we will get some clients, which
> allow blacklisting "only with XX server, version YY", and servers, which
> have client-side-configured blacklist, but only if you use XX client.
> This will break one of greate features of Jabber: whatever client you
> use, you can do the same --- use the same buddy-list, the same gateways
> etc.

You can still use the same clients to access the same features of Jabber.
These are specific server configuration issues that don't need to be
implemented on every server (or so was my impression from earlier posts).
So even if you create a Jabber server blocking standard there is still no
guarantee that any client can access any server and configure server-side
blocking... Some client and some servers won't support it.

So why not allow servers to implement their own blocking administration
interfaces as they see fit?  This is the way things are in the wooly world
of email and no one seems to have a problem with it.  Every email server has
a different way of configuring mail forwarding and spam blocking for
example.  Most use simple web forms to great effect.  I greatly fear that
the Jabber standards will be bloated with peripheral protocols that don't
offer significant benefits from standardization.

Is there real harm in having users setup their accounts using a web
interface?  If so what are they?

If we feel that we must have the ability to configure things like
server-side blocking using a Jabber standard, perhaps we would be better
served with a generic user account configuration protocol... Hey isn't that
jabber:iq:register with perhaps jabber:iq:forms?

Or maybe creating something like generic web <form/>s for obtaining and
submitting user editable information... Like maybe a jabber:x:forms or just
embedding html web pages into <message/> bodies.  At some point though we're
just re-inventing http over Jabber.  And that seems a bit silly when we
already have the web and a browser on every desktop.

Perhaps the best solution is simply a way to query for the web URLs of
server configuration forms that can either be displayed in an HTML-capable
Jabber client, or sent to the separate web browser?


Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

More information about the Standards mailing list