[hybi] Fragment and extensions
Greg Wilkins <gregw@intalio.com> Wed, 20 April 2011 07:36 UTC
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfc.amsl.com
Delivered-To: hybi@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7C6CE0698 for <hybi@ietfc.amsl.com>; Wed, 20 Apr 2011 00:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.777
X-Spam-Level:
X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L2TDiUYr-Lo for <hybi@ietfc.amsl.com>; Wed, 20 Apr 2011 00:36:52 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2A3D0E0697 for <hybi@ietf.org>; Wed, 20 Apr 2011 00:36:52 -0700 (PDT)
Received: by vws12 with SMTP id 12so461246vws.31 for <hybi@ietf.org>; Wed, 20 Apr 2011 00:36:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.95.138 with SMTP id dk10mr5027491vdb.277.1303285011616; Wed, 20 Apr 2011 00:36:51 -0700 (PDT)
Received: by 10.52.158.104 with HTTP; Wed, 20 Apr 2011 00:36:51 -0700 (PDT)
Date: Wed, 20 Apr 2011 17:36:51 +1000
Message-ID: <BANLkTikHAtNXuaUCv-35MpPOUMkqeJ+pmw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Andy Green <andy@warmcat.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Hybi <hybi@ietf.org>
Subject: [hybi] Fragment and extensions
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 20 Apr 2011 07:36:52 -0000
Currently the spec says in 4.4: o An intermediary MAY change the fragmentation of a message if the message uses only opcode and reserved bit values known to the intermediary. I'm not sure if that is strong enough. Imagine an extension that sends digital signatures of the payload as extension data, so a frame might look like: DATA_OP length signature message. An intermediary will see neither an opcode nor a resource bit that it does not understand, so it is free to fragment that frame, which will break that extension. I propose that the spec should say: o An intermediary MUST NOT change the fragmentation of a message unless all extension that apply to the message are known to the intermediary. Furthermore, since an intermediary that does not know all the extensions that apply to a connection, must neither fragment nor aggregate frames, then I propose that we allow an extension to interleave the fragments of a message. o Extensions MAY interleave fragments one one message between fragments of a separate message. As such, an end point that accepts connections with such extensions must be capable of handling the interleaving when aggregating the frames of the messages. In the absence of any interleaving extension, an end point MUST NOT interleave the fragments of different messages. I believe that such a change will allow simpler MUX implementations, and the specification says that MUX is one of the two identified reasons for fragmentation, yet currently fragmentation cannot be used for MUX because you cannot interleave messages. regards
- [hybi] Fragment and extensions Greg Wilkins
- Re: [hybi] Fragment and extensions Greg Wilkins