[standards-jig] Breaking Standards [was: disco, x:data, etc...]

David 'TheRaven' Chisnall theraven at sucs.org
Fri Feb 21 23:33:28 UTC 2003


Extremely well said.  Anyone who feels that this is overstated should 
take a look at the World Wide Web.  There are a set of approved 
standards for HTML, but over the years Microsoft and Netscape have added 
their own 'extensions'.  Since IE has the larger market share, web page 
designers now often only bother testing if their pages work in IE, not 
whether they comply with the standards.  The result is that a lot of the 
web is only usable by users of a certain browser.  Jabber, as an open 
standard, is often compared to email, a success story for open standards 
exemplified by the fact that I can access my email using PINE, Mozilla 
mail or even Outlook with no problems.  This is what we need to aim for 
and I would hate to see the Jabber protocol become as fragmented as the 
w3c recommendations because of lazy and selfish developers who feel that 
'embrace and extend' is an acceptable policy when it comes to an open 
I believe it has been suggested before, but I think we need some form of 
Jabber Certification, given to clients and servers which conform to the 
specification.  Microsoft offered two levels of certification 'Works 
with Windows' and 'Designed for Windows', perhaps we should offer a 
similar pair.  The 'Works with Jabber' certification should be given to 
any client, server or library that implements a subset of the 
specification, and does nothing that would break other, conforming, 
implementations while the 'Designed for Jabber' certification would be 
reserved for products which implement the entire specification. 
 Products such as the one described in this thread which intentionally 
break the specification on a whim of the designer, and can potentially 
fail to inter-operate with other clients should be denied use of the 
Jabber trademark, since they are not implementations of Jabber.  

David Chisnall

Matthew A. Miller wrote:

>As I and others have pointed out, you are breaking a number of
>standards.  The time to question them has passed.  A number of solutions
>to your particular problems have been presented, but refused.  Instead,
>we have a case of trying to modify the standards because of a single
>implementation refusing to comply.
>A community is only as strong as the cooperation of its members, and
>standards are the letter for that cooperation.  Instead of cooperating,
>this implementation has seen fit to toss it aside, and for what?  A
>quick and potentially ill-conceived "fix" to a problem that has many
>solutions which are seen as more elegant and practical by the community.
>The suggested changes to the addressing scheme of Jabber and XMPP is not
>a simple, minor, or agreed-to task.  The current standards for
>addressing in Jabber and XMPP have reached consensus, even acceptance,
>by the vast majority of the community.  Many existing implementations
>rely this standard.  We consider it a great success that we have such
>interoperability, especially when similar efforts elsewhere cannot begin
>to boast of such feats.
>But yet, by implementing and relying on this "non-standard", to the
>exclusion of other solutions, begins to defeat the very point to
>standardization, and break down our community.  We now have
>implementations that are not merely obsolete, but purposefully
>non-compliant.  That this implementation "interoperates" with another
>implementation from the same "vendor" is laughable.  This is not
>cooperating with the community; this is destroying it.
>Disliking the realities of the standards-process is irrelevant, because
>it does not change that reality.  The "simple task" spoken of is *not*
>simple, because it requires consensus before it can be approved.  That
>consensus is currently nonexistent.
>Using xml:lang as an example for why node should be added is not
>relevant.  xml:lang is there to meet the XMPP charter, which also has
>nothing to do with addressing.  Though very helpful, its presence is
>also not critical to the successful interoperability of
>implementations.  On other hand, the addition of "node" to the
>addressing scheme does have a critical impact.  The current requirements
>for this are unclear and not well exemplified.  The current addressing
>scheme was and is not considered deficient, except by a very vocal, but
>very small minority.

More information about the Standards mailing list