[hybi] thewebsocketprotocol #40 (new): Clarify binary/utf-8 mixed handling

"hybi issue tracker" <trac@tools.ietf.org> Thu, 10 February 2011 00:32 UTC

Return-Path: <trac@tools.ietf.org>
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 6AE4D3A672F for <hybi@core3.amsl.com>; Wed, 9 Feb 2011 16:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level:
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, 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 Z6oDwMzD9Ody for <hybi@core3.amsl.com>; Wed, 9 Feb 2011 16:32:08 -0800 (PST)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CBE733A682D for <hybi@ietf.org>; Wed, 9 Feb 2011 16:32:07 -0800 (PST)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1PnKSH-00030o-Km; Wed, 09 Feb 2011 16:32:17 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: hybi issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: g_e_montenegro@yahoo.com
X-Trac-Project: hybi
Date: Thu, 10 Feb 2011 00:32:17 -0000
X-URL: http://tools.ietf.org/hybi/
X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/hybi/trac/ticket/40
Message-ID: <063.e489b6d352cc1192d00acf7f96150ea7@tools.ietf.org>
X-Trac-Ticket-ID: 40
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: g_e_montenegro@yahoo.com, hybi@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: hybi@ietf.org
Subject: [hybi] thewebsocketprotocol #40 (new): Clarify binary/utf-8 mixed handling
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
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: Thu, 10 Feb 2011 00:32:09 -0000

#40: Clarify binary/utf-8 mixed handling

 It can be confusing to mix binary and utf-8 frames in one tcp-like stream.
 For example, what will the current text-only JS Websocket API do if
 suddenly binary starts appearing?
 Additionally, when only partial frames may be available, it is expensive
 to verify that this is indeed a valid UTF-8 stream (protocol
 implementation needs to take into account multi-byte characters and end of
 current data payload).  If binary has been negotiated for this session,
 processing can be optimized accordingly.

 Proposal: allow negotiation to clarify if a stream will not mix binary and
 text in order to enable optimizing for the binary-only case.

-- 
--------------------------------------+-------------------------------------
 Reporter:  g_e_montenegro@…          |       Owner:     
     Type:  defect                    |      Status:  new
 Priority:  major                     |   Milestone:     
Component:  thewebsocketprotocol      |     Version:     
 Severity:  -                         |    Keywords:     
--------------------------------------+-------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/hybi/trac/ticket/40>
hybi <http://tools.ietf.org/hybi/>
The Hypertext-Bidirectional (HyBi) working group will seek
standardization of one approach to maintain bidirectional
communications between the HTTP client, server and intermediate
entities, which will provide more efficiency compared to the current
use of hanging requests.