[hybi] [Technical Errata Reported] RFC6455 (4672)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC6455,
"The WebSocket Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=4672

--------------------------------------
Type: Technical
Reported by: Anton Dunaev <[e-mail]>

Section: 5.6

Original Text
-------------
   Data frames (e.g., non-control frames) are identified by opcodes
   where the most significant bit of the opcode is 0.  Currently defined
   opcodes for data frames include 0x1 (Text), 0x2 (Binary).  Opcodes
   0x3-0x7 are reserved for further non-control frames yet to be
   defined.

   Data frames carry application-layer and/or extension-layer data.  The
   opcode determines the interpretation of the data:

   Text

      The "Payload data" is text data encoded as UTF-8.  Note that a
      particular text frame might include a partial UTF-8 sequence;
      however, the whole message MUST contain valid UTF-8.  Invalid
      UTF-8 in reassembled messages is handled as described in
      Section 8.1.

   Binary

      The "Payload data" is arbitrary binary data whose interpretation
      is solely up to the application layer.


Corrected Text
--------------
   Data frames (i.e., non-control frames) are identified by opcodes
   where the most significant bit of the opcode is 0.  Currently defined
   opcodes for data frames include 0x00 (Continuation), 0x1 (Text) and
   0x2 (Binary).  Opcodes 0x3-0x7 are reserved for further non-control
   frames yet to be defined.

   Data frames carry application-layer and/or extension-layer data.  The
   opcode determines the interpretation of the data:

   Text

      The "Payload data" is text data encoded as UTF-8.  Note that a
      particular text frame might include a partial UTF-8 sequence;
      however, the whole message MUST contain valid UTF-8.  Invalid
      UTF-8 in reassembled messages is handled as described in
      Section 8.1.

   Binary

      The "Payload data" is arbitrary binary data whose interpretation
      is solely up to the application layer.

   Continuation

      These frames MUST be always preceeded by either Text or Binary
      frame with FIN bit clear (See Section 5.2). The "Payload data"
      contains next fragment (See section 5.4) of the message whose
      transmission were opened by the latest Text or Binary frame and
      MUST be interpreted in the same way as the initial fragment of
      the message.


Notes
-----
For any other opcode defined frames are explicitly listed and described in either Section 5.5 or Section 5.6. But continuation frame is not. 

Formally it matches definition of data frame (given in section 5.6) as the most significant bit of its opcode is 0. Logically it should be data frame too. But it is unclear whether there are two categories of frames (data and control) or the Continuation frame represents the third.

One could guess though that Continuation frame is a data frame from the content of the section 5.5.1 stating that "An endpoint MAY delay sending a Close frame until its current message is sent (for instance, if the majority of a fragmented message is already sent, an endpoint MAY send the remaining fragments before sending a Close frame)". This fragment clarifies that Close frame is sent after an endpoint finished message transmission. Thus such interpreation would be consistent with the Section 5.5.1 stating that "The application MUST NOT send any more data frames after sending a Close frame".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17)
--------------------------------------
Title               : The WebSocket Protocol
Publication Date    : December 2011
Author(s)           : I. Fette, A. Melnikov
Category            : PROPOSED STANDARD
Source              : BiDirectional or Server-Initiated HTTP APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG