Re: [hybi] WebSocket Version Numbers

Peter Saint-Andre <> Tue, 21 June 2011 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DF9D11E8125 for <>; Tue, 21 Jun 2011 06:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.239
X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ISLbVJmNjC74 for <>; Tue, 21 Jun 2011 06:56:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF6DC11E80AE for <>; Tue, 21 Jun 2011 06:56:18 -0700 (PDT)
Received: from squire.local ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 6AA06400F9; Tue, 21 Jun 2011 07:56:55 -0600 (MDT)
Message-ID: <>
Date: Tue, 21 Jun 2011 07:56:14 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bob Gezelter <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
OpenPGP: url=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050006040501050106030905"
Subject: Re: [hybi] WebSocket Version Numbers
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jun 2011 13:56:19 -0000

On 6/21/11 7:10 AM, Bob Gezelter wrote:
> I?aki, Julian, Salvatore, and all,
> Some may consider version number information an anti-pattern, but I
> believe that this belief is misplaced.
> Version numbering becomes a problem when it is a stalking horse for poor
> design and very incompatible dialects. It is these fundamental
> incompatibilities that are the true anti-pattern. Properly implemented
> version number identification is an important tool for troubleshooting
> problems caused by the need to maintain backward compatible operations
> with a wide collection of client and server systems, who almost
> certainly cannot be upgraded on a synchronized schedule.
> Indeed, systems that externally implement version number based
> restrictions experience far fewer problems than systems without such
> checks.
> I would suggest that the final accepted RFC use a major/minor revision
> scheme of 1.0. A future RFC would have a revision number of 2.0.
> Intermediate drafts would have a minor version increment (e.g., 1.1,
> 1.2, ...).

Once again I recommend borrowing from the text in RFC 6120 if
appropriate, see Section 4.7.5...


   The numbering scheme for XMPP versions is "<major>.<minor>".  The
   major and minor numbers MUST be treated as separate integers and each
   number MAY be incremented higher than a single digit.  Thus, "XMPP
   2.4" would be a lower version than "XMPP 2.13", which in turn would
   be lower than "XMPP 12.3".  Leading zeros (e.g., "XMPP 6.01") MUST be
   ignored by recipients and MUST NOT be sent.

   The major version number will be incremented only if the stream and
   stanza formats or obligatory actions have changed so dramatically
   that an older version entity would not be able to interoperate with a
   newer version entity if it simply ignored the elements and attributes
   it did not understand and took the actions defined in the older

   The minor version number will be incremented only if significant new
   capabilities have been added to the core protocol (e.g., a newly
   defined value of the 'type' attribute for message, presence, or IQ
   stanzas).  The minor version number MUST be ignored by an entity with
   a smaller minor version number, but MAY be used for informational
   purposes by the entity with the larger minor version number (e.g.,
   the entity with the larger minor version number would simply note
   that its correspondent would not be able to understand that value of
   the 'type' attribute and therefore would not send it).



Peter Saint-Andre