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

Shawn Wilton shawn at black9.net
Mon Jan 21 22:41:02 UTC 2002

I just want to point out one more time, that the idea of message rendering
that I posted was not that you are forced to implement it, but rather that
every client author has something to work off of.  A standard list of
suggested maps and icons if you will.  A lot of clients implement different
parse maps and if they added the standard ones as well, then that could go a
long way in terms of useability.  People keep reading that and getting the
idea that you will have to format the text in some specific way and that's
just a crock of butter.  This is more of an optional guideline if you will.

As for the privacy, you have to have a standard so that it works across
clients and servers, hands down.

-----Original Message-----
From: standards-jig-admin at jabber.org
[mailto:standards-jig-admin at jabber.org]On Behalf Of Julian Missig
Sent: Monday, January 21, 2002 1:32 PM
To: standards-jig at jabber.org
Subject: Re: [standards-jig] Constraining standards? (was: Discussion on
JEP-0016: Server-Based Privacy Rules)

The difference between emoticons and server-side blocking is that
server-side blocking requires a specific protocol, and I do feel we
should continue to define specific protocols - no one is required to
implement a specific protocol, but if they choose to follow the standard
it will work with all clients and servers which also choose to implement it.

Emoticons, on the other hand, are definitely very client-specific and I
would argue should probably not be standardized... except for the fact
that it would be nice to at least have a suggested list of mappings
between text and icons - because that's *almost* protocol.

I don't think anything implementation specific has become a Jabber
standard yet, and emoticons will most likely just be a suggested list.

I would prefer if we provided as many protocol standards as we can, as
long as they do not overlap and are good standards. No one has to
implement all of the extensions, but the standards are there for
interoperability's sake. I want Jabber clients and servers to continue
working across platforms, corporations, and implementations as much as
possible. The point of Jabber is interoperability, and we lose that if
everyone goes their own way.

email: julian at jabber.org
jabber:julian at jabber.org

Iain Shigeoka wrote:

> Hello all,
> I've been reading the discussions on server-based privacy, and the talk on
> jdev about formatting (and emoticons) and am starting to feel like Jabber
> approaching a critical juncture.  So this email is a question of whether
> anyone else has noticed it, if I'm imagining everything, and if it is
> significant.
> My feeling is that Jabber is getting to a point where we must decide where
> the Jabber standards end and "implementation specific issues" begins.
> take server-based privacy as an example.  Is that really something that
> should be in the Jabber standards?  Or should that be an implementation
> specific issue.  Shouldn't we let individual server implementations decide
> about whether to offer the feature and provide their own tools for
> providing, administering, etc that feature?
> If we do allow server-based privacy, shouldn't we specify how to
> user messaging limitations (like bandwidth throttling) as a Jabber
> How about limiting other resources like the number of simultaneous logins
> allowed by a single user account?  How about server administration?  How
> about server installation and deployment?  Where do we end?
> On the client side, things are also slipping into what I consider
> implementation specific details.  A jabber standard on emoticons?  Is that
> really necessary?  Shouldn't we allow clients to do whatever they want
> inside of messages?
> I always envisioned it as a market share issue and not a Jabber standard
> problem.  The client can add these features (like emoticons) as they see
> and their own users will see these advanced features.  If others "chase
> lights" they can emulate the same support until it becomes a de facto
> standard...  However, until that time, I don¹t think there is any reason
> a Jabber standard per se.
> I know the argument.  We want to provide a "uniform user experience" when
> accessing Jabber.  I should be able to specify a smiley on the "client by
> Foo Co" and see it on the "client by Bar Inc" exactly the same.  But is
> really what we want?
> My analogy is between Posix and Windows.  Posix is a minimum specification
> for how an operating system works.  Kernel interfaces, etc.  There is an
> extension that describes a very minimal (shell + ultra-basic tools) user
> access to the system.  And that's it.
> Windows is also a specification for how an operating system works.
> in the interests of providing a uniform user experience, it enforces look
> and feel, workflow, a large number of user tools, etc.  It worries about
> things like how emoticons look and how buttons click.
> Do we want Jabber to be a standard that is more Posix or Windows?  Please
> try to avoid any bias against the latter for reasons that extend beyond
> way its used in this metaphor.  There is a lot of good that can come from
> specifying everything down to how emoticons look.  Take the AOL dominance
> the online market as an example.
> I personally like a minimalist standard that provides the maximum
> flexibility for implementation variations that can give people competitive
> advantages.  I'd rather not see Jabber become one uniform, look alike,
> alike system.  I want to see one developer espousing the benefits of their
> server's blacklisting, while another shouting the benefits of their
> whitelisting system and another saying that neither works, and only its
> advanced anti-spam expert system can provide the level of comfort you
> Thoughts?
> -iain

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

More information about the Standards mailing list