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

Iain Shigeoka iainshigeoka at yahoo.com
Mon Jan 21 20:04:26 UTC 2002


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 is
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.  Let's
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 administer
user messaging limitations (like bandwidth throttling) as a Jabber standard?
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 fit
and their own users will see these advanced features.  If others "chase tail
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 for
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 that
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.  However,
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 the
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 of
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, work
alike system.  I want to see one developer espousing the benefits of their
server's blacklisting, while another shouting the benefits of their server's
whitelisting system and another saying that neither works, and only its
advanced anti-spam expert system can provide the level of comfort you need.

Thoughts?

-iain


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




More information about the Standards mailing list