[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