[standards-jig] Constraining standards? (was: Discussion on JEP-0016: Server-Based Privacy Rules)
stpeter at jabber.org
Tue Jan 22 22:13:01 UTC 2002
> chase taillights. I just don't like the idea of us _specifying_ things that
> are a matter of style or implementation.
Actually I would say that the job of the Jabber Software Foundation is
precisely to specify things. The question is what we're here to specify.
This is wrapped up with the question of what it means to be "Jabber
Powered". The early discussions about this (last summer) made it clear
that we would probably have levels of compliance. If your custom client
doesn't support <message/>, <presence/>, and <iq/> (and some reasonable
set of namespaces, attributes, and sub-elements of those) then you're not
Jabber compliant in any sense of the term. So we need to define that base
level of compliance. And that's part of what the Standards JIG is here to
do -- define what is core to Jabber as an IM system (or XML routing system
if you like that way of looking at things, though I see that as more
Beyond that base level of standards (and standards compliance) lies the
realm of the optional. Here too the Jabber Software Foundation has a role
to play, IMO. So you'd like your Jabber client to suppose formatted text?
Well, the JSF has a JEP on that which says if you want to do formatted
text, here is an accepted way to do it. Does that mean your special client
can't sent some bastardized RTF instead of XHTML (let's say)? No. Does
that mean if your special client sends bastardized RTF that it's not
JabberPowered? No. It's compliant with the base standards and so it is
JabberPowered but it implements certain optional functionality (however we
define optional) in a way other than the recommended Jabber standard.
Heck, we don't even always need to have one standard for optional stuff,
we can have two recommended standards (as for instance would come out of
> How Clients configure blocking should also be out of the spec. It can be an
> IQ extension but it should also be just as possible to support blocking but
> 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 however
> it may be done).
Well obviously there are grey areas and topics that some people think
should be outside the scope of any Jabber standards other than market
acceptance. Personally I feel that if we clearly define what is core, then
we can safely specify optional areas with the understanding that "if you
want your Jabber client to be able to talk with a server in order to
configure server-side message blocking, here is the recommended way to do
it". That doesn't mean Jabber Server X can't implement such configuration
via a user-accessed web page or even a call center that users have to
phone in to (ick!). We're in the realm of the optional here. But to me
it's helpful to have recommended standards within the realm of the
optional rather than having standards only within the realm of core
functionality and utter laissez-faire outside the core.
email+jabber: stpeter at jabber.org
More information about the Standards