Subject: [hybi] #15: Changes to Section 1.2 - Protocol Overview

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

#15: Changes to Section 1.2 - Protocol 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 1.2 - Protocol Overview. There is good normative content here that
 is too detailed for the overview and that should be in section 4 instead
 (as it is wasted in the non-normative section 1).

   * Change the text "On the network layer, a message may be represented as
 one or more frames." to be "The websocket message does not necessarily
 correspond to any network layer framing.".. This is more correct as the
 network layer may coalesce as well as fragment.

   * strike the paragraph beginning "to close" as it too low level of a
 detail to be considered part of the overview and is redundant to the
 normative text.

   * For similar reasons, strike the paragraph "the protocol is designed"
 but add the more summary oriented sentence "This version of the protocol
 defines six frame types and leaves ten reserved for future use." to the
 end of the section 1.2 paragraph that begins "Data is sent". The original
 sentence doesn't reflect the current allocation of op codes.

   * move the ABNF portion to normative section 4.2.

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

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