IETF Logo Mail Archive

Re: [hybi] Framing Take VI (a compromise proposal)

John Tamplin <jat@google.com> Fri, 13 August 2010 21:26 UTC

Return-Path: <jat@google.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 72B953A6969 for <hybi@core3.amsl.com>; Fri, 13 Aug 2010 14:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.834
X-Spam-Level:
X-Spam-Status: No, score=-105.834 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 UINM0qCSNdR3 for <hybi@core3.amsl.com>; Fri, 13 Aug 2010 14:26:18 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5A1163A691A for <hybi@ietf.org>; Fri, 13 Aug 2010 14:26:18 -0700 (PDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o7DLQs8L003514 for <hybi@ietf.org>; Fri, 13 Aug 2010 14:26:54 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281734814; bh=jwKxgR6zNOi/txCz5Psa6XUYEPM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hX61ukeCG9Z5Uk8/G972IyM0tf2a4HEVLyPLpoFUoZjiLAi7YSPxV10axakUOUBC4 dabBMdSHT9IyhWbnnifmQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=P1NlU+f4QSCi+EgDf/TS1SgIs6gxhFR/+cppvXtEnf9Ti5Hg9vYQ1oUnv1RVem8Mn 4Sikzt914sIUBIPq/4tyg==
Received: from gwj18 (gwj18.prod.google.com [10.200.10.18]) by wpaz24.hot.corp.google.com with ESMTP id o7DLQrFj028277 for <hybi@ietf.org>; Fri, 13 Aug 2010 14:26:54 -0700
Received: by gwj18 with SMTP id 18so1830250gwj.2 for <hybi@ietf.org>; Fri, 13 Aug 2010 14:26:53 -0700 (PDT)
Received: by 10.150.53.21 with SMTP id b21mr2682000yba.350.1281734813555; Fri, 13 Aug 2010 14:26:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.60.3 with HTTP; Fri, 13 Aug 2010 14:26:33 -0700 (PDT)
In-Reply-To: <AANLkTim5e0T3wLOnpFXpKtKtg1zAaHtzRUxgYhfCQNOe@mail.gmail.com>
References: <AANLkTi=TBXO_Cbb+P+e2BVfx69shkf8E1-9ywDh_Y+Kz@mail.gmail.com> <AANLkTimJOGWgV6rx5JJYSJMC26OzQzskzVtkYz0L_EAg@mail.gmail.com> <AANLkTim5e0T3wLOnpFXpKtKtg1zAaHtzRUxgYhfCQNOe@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Fri, 13 Aug 2010 17:26:33 -0400
Message-ID: <AANLkTim7Eg2HSG1A7Vmz7syUQY8f-ZjBGrD8ZXx0=uyG@mail.gmail.com>
To: ifette@google.com
Content-Type: multipart/alternative; boundary="000e0cd30800421d7a048dbb24b7"
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Framing Take VI (a compromise proposal)
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: Fri, 13 Aug 2010 21:26:19 -0000

On Fri, Aug 13, 2010 at 5:20 PM, Ian Fette (イアンフェッティ) <ifette@google.com>wrote:

> This point has been argued extensively enough on the list that I don't
> think anything I say here is going to be new.
>

Not to mention support for fragmentation has been declared a consensus
requirement without objection on this list.


>  - I don't see why we would need to flag fragmentation frames using
>> reserved bits rather than just using the frame type byte mechanic.
>> Just define four frame types for text and four frame types for binary
>> when we add binary (not fragmented, fragment start, fragment middle,
>> fragment end).
>>
>
Isn't that using two bits to define fragmentation the same way, except now
an implementation has to know opcodes 0, 14, 15, 23, and 25 are fragment
start codes, etc?  It seems that fragmentation should be supported across
all frame types -- why would one type of frame want to omit fragmentation
support?

-- 
John A. Tamplin
Software Engineer (GWT), Google

v2.23.0 | Report a Bug | By Email