Subject: [hybi] #16: Changes to Section 4.1 - normative Data Framing Overview

From: "hybi issue tracker" <[email-masked]>
Date: Mon, 27 Sep 2010 17:11:20 -0000

#16: Changes to Section 4.1 - normative Data Framing Overview
----------------------------------+-----------------------------------------
 Reporter:  sm+ietf@…             |       Owner:     
     Type:  defect                |      Status:  new
 Priority:  major                 |   Milestone:     
Component:  thewebsocketprotocol  |     Version:     
 Severity:  Active WG Document    |    Keywords:     
----------------------------------+-----------------------------------------
 Message posted by Patrick McManus on 2 Sept, 2010:

 Section 4.1 - normative Data Framing Overview

   * strike the sentence "The base framing protocol is deliberately kept
 simple so that simple implementations may ignore advanced features."
 There is no definition of simple implementations, no definition of
 advanced features, and no definition of what ignore might mean in this
 context. What is an implementor to do with it? :)..  I personally don't
 think we need the text at all, but if we want it move it to a non-
 normative section.

   * update the remainder of 4.1 to standards-speak: "In the absence of
 extensions negotiated during the opening handshake (Section 5), all
 reserved bits MUST be 0 and reserved opcode values MUST NOT be used."..
 actually this probably belongs somewhere other than the overview.

   * Add to that 4.1 paragraph the text "A data frame MAY be transmitted by
 either the client or the server at any time after handshake completion and
 before that host has generated a close message." That probably means we
 need a normative definition of client and server somewhere - but I think
 this is an important thing to say in a place other than section 1.

 http://www.ietf.org/mail-archive/web/hybi/current/msg04005.html

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/hybi/trac/ticket/16>
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.