IETF Logo Mail Archive

Re: [hybi] Proposed way forward for WebSockets

Lars Eggert <lars.eggert@nokia.com> Tue, 27 July 2010 10:56 UTC

Return-Path: <lars.eggert@nokia.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 E5AAD3A6A67 for <hybi@core3.amsl.com>; Tue, 27 Jul 2010 03:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.496
X-Spam-Level:
X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 DkmYbqjo7r93 for <hybi@core3.amsl.com>; Tue, 27 Jul 2010 03:56:14 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 72DF73A6A44 for <hybi@ietf.org>; Tue, 27 Jul 2010 03:56:13 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6RAuRV1002602; Tue, 27 Jul 2010 13:56:32 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 13:56:30 +0300
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 13:56:30 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6RAuTUb027944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jul 2010 13:56:30 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary="Apple-Mail-62--875080007"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <AANLkTimTuyObCs=ny0zdYgx2Oy2Ryt2e_9D9B-cKRspZ@mail.gmail.com>
Date: Tue, 27 Jul 2010 12:41:54 +0200
Message-Id: <C19CA9CA-3DC4-4242-9139-86029D32EC6C@nokia.com>
References: <ECF0E97F-1DA2-4662-BA48-F68B65AA8179@apple.com> <4C4D66AF.9030905@opera.com> <Pine.LNX.4.64.1007270030120.24444@ps20323.dreamhostps.com> <AANLkTi=fx=Yfm_pe9-pdCc=5sKRP=dNfDEBYCKNHFOmH@mail.gmail.com> <op.vghnjpex64w2qv@annevk-t60> <AANLkTik5AB=UPJ47z8tEnVygJodPVAmppeXUymMBz+9n@mail.gmail.com> <op.vghpu5z464w2qv@annevk-t60> <AANLkTimTuyObCs=ny0zdYgx2Oy2Ryt2e_9D9B-cKRspZ@mail.gmail.com>
To: Adam Barth <ietf@adambarth.com>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 27 Jul 2010 13:56:21 +0300 (EEST)
X-OriginalArrivalTime: 27 Jul 2010 10:56:30.0452 (UTC) FILETIME=[5E7A3B40:01CB2D7A]
X-Nokia-AV: Clean
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Proposed way forward for WebSockets
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: Tue, 27 Jul 2010 10:56:15 -0000

Hi,

On 2010-7-27, at 10:49, Adam Barth wrote:
> On Tue, Jul 27, 2010 at 9:03 AM, Anne van Kesteren <annevk@opera.com> wrote:
>> This is one of the
>> most basic extensibility mechanisms there is. I.e. MUST not generate and
>> MUST ignore so that in the future we CAN generate and CAN do something...
> 
> Anne, for whatever reason, folks at the IETF don't seem to understand
> this design pattern right away.  It's some sort of cultural mismatch
> between browser folks (who using this pattern all the time for
> extensibility and robustness) and IETF folks.  In my experience, folks
> understand after I explain it to them, but you shouldn't assume
> they'll understand it without explanation.

you must be kidding. That's probably the most common protocol design pattern that you'll find in the RFCs.

Lars

v2.23.0 | Report a Bug | By Email