Re: [hybi] Versioning is a anti-pattern

David Orchard <orchard@pacificspirit.com> Mon, 06 September 2010 05:49 UTC

Return-Path: <dorchard100@gmail.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46243A68A0 for <hybi@core3.amsl.com>; Sun, 5 Sep 2010 22:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3iVqhEKx5w6 for <hybi@core3.amsl.com>; Sun, 5 Sep 2010 22:49:51 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3DBFB3A6887 for <hybi@ietf.org>; Sun, 5 Sep 2010 22:49:51 -0700 (PDT)
Received: by bwz9 with SMTP id 9so3898996bwz.31 for <hybi@ietf.org>; Sun, 05 Sep 2010 22:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=OcQZB5lmRTiIpG+0gJHbcWU7qqB63atkh4NDC8gHZ2w=; b=uctX+wG32kmLz/4VK0hWbW9fmXUabZbsF+Yc+IfgmHGtKca8Uf3LtTjCea+oiM88bS FAGgWiVFvkIzNPAZe0WnKBKemmZWEqrRHy4cN1P7LcpBp9wNqbG1qvuk5ONVwBYNBQln 35zidqXTlDAkJ+l5LyEJGocaK21SLlxM4Yb8M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=e/h9f+ATtl/sNUvruj2gwzYH1/vEQLrM89+oiXevRIRW3+buw4CjFoWvASjdvqfUfr rhzSy1uCJqnjwQxfvRzgINQTba39ml0AaTnavxaxQ/W5g4+7BC5R5oedmtdxbTYiJSFL PPoo1J4IkKqUKDoTp2y1wqU23SdliaDDshF6A=
MIME-Version: 1.0
Received: by 10.204.61.133 with SMTP id t5mr2131760bkh.4.1283752218421; Sun, 05 Sep 2010 22:50:18 -0700 (PDT)
Sender: dorchard100@gmail.com
Received: by 10.204.104.4 with HTTP; Sun, 5 Sep 2010 22:50:18 -0700 (PDT)
In-Reply-To: <4C847F06.70903@it.aoyama.ac.jp>
References: <20100901224502.0519B3A687C@core3.amsl.com> <AANLkTikP1CF22fL0rBniXmrxEoBAbTNfzP9kyiNA4nbb@mail.gmail.com> <AANLkTi=_1m36ThFZTH_aGE_Unz0KTeexJq_74UGr2j+u@mail.gmail.com> <alpine.DEB.2.00.1009022022090.7470@tvnag.unkk.fr> <AANLkTi=yQyvX_z3NhvNc4dFjfHwTH2edhYM2LukZDfsm@mail.gmail.com> <4C847F06.70903@it.aoyama.ac.jp>
Date: Sun, 05 Sep 2010 22:50:18 -0700
X-Google-Sender-Auth: giYsOdJYEIkPu5NFvPf03tT-hFo
Message-ID: <AANLkTik+91Y699oMgdGtWi+DifL=_T9ocaimcV7nHsBS@mail.gmail.com>
From: David Orchard <orchard@pacificspirit.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: hybi <hybi@ietf.org>
Subject: Re: [hybi] Versioning is a anti-pattern
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2010 05:49:53 -0000

Martin, you said:

> Yes, indeed. The version number would only be changed if there were some
> very basic changes in the protocol. The tremendous difficulty isn't so much
> coming from a fundamental problem with versioning (if there indeed were some
> very basic protocol changes, there would probably be wide agreement with
> changing the version number) but from the fact that nobody currently is
> interested in very basic changes in the HTTP protocol (if you exclude this
> group :-).

Which is accurate, but I think that is partially because of what I
mentioned before, that the HTTP version identifier semantics weren't
defined enough.  If it was "easy" to version HTTP from 1.1 to say 1.2
with some optional components, then we may have done so.  But because
HTTP did not do anything like what I mentioned before, such as
something akin to "Minor versions are guaranteed to be compatible
changes and any unknown components may be ignored and must not cause a
fault in a receiver" or somesuch wording, than 1.1 made it very
difficult to create a version of HTTP that was forwards compatible
with existing receivers.

Cheers,
Dave