IETF Logo Mail Archive

Re: [hybi] It's time to ship

Greg Wilkins <gregw@webtide.com> Mon, 10 January 2011 06:22 UTC

Return-Path: <gregw@intalio.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 992E83A6A4A for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 22:22:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.928
X-Spam-Level:
X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 OvnWnKM0i1ac for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 22:22:18 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B52CC3A6A49 for <hybi@ietf.org>; Sun, 9 Jan 2011 22:22:18 -0800 (PST)
Received: by qwi2 with SMTP id 2so3722782qwi.31 for <hybi@ietf.org>; Sun, 09 Jan 2011 22:24:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.53.213 with SMTP id n21mr26564349qag.399.1294640671478; Sun, 09 Jan 2011 22:24:31 -0800 (PST)
Sender: gregw@intalio.com
Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 22:24:31 -0800 (PST)
In-Reply-To: <AANLkTikgB+Ju-k0obs9it7TOsy8B1jaCYv8zBpB9dEa_@mail.gmail.com>
References: <AANLkTim2VGfH2FiJ4iH85wYiuXNKQ1Arh1C1Kg4M58Fs@mail.gmail.com> <20110109224228.GU5743@1wt.eu> <AANLkTikgB+Ju-k0obs9it7TOsy8B1jaCYv8zBpB9dEa_@mail.gmail.com>
Date: Mon, 10 Jan 2011 07:24:31 +0100
X-Google-Sender-Auth: tFKVc6bjp9MN3oGuXAkfT_kmAm4
Message-ID: <AANLkTimBrf=c57s5ZP-ZYuyt_25wax6BOCSsyaQf+K3n@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: ifette@google.com
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] It's time to ship
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, 10 Jan 2011 06:22:19 -0000

2011/1/10 Ian Fette (イアンフェッティ) <ifette@google.com>:
>>  - several people on the list asked for the ability to be able to disable
>>    the masking in some well-controlled environments (eg: server-to-server
>>    communications). I see no provisions for this.
>>
>
> There's nothing that would prevent you from writing an extension that would
> disable the masking, from my understanding.

By masking the framing, the masking inherently becomes part of the framing.
Intermediaries will need to be written that understand the masking,
just so that they can parse the framing.

Thus you cannot turn masking off unless you modify every WS component
in the chain with knowledge of the no-masking extension.

The whole point of extensions was to allows opaque extension data to
be associated with frames so that it is only handled by components
that care about it.

v2.23.0 | Report a Bug | By Email