[hybi] [Technical Errata Reported] RFC6455 (4672)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 19 April 2016 01:13 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34F612DC99 for <hybi@ietfa.amsl.com>; Mon, 18 Apr 2016 18:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.898
X-Spam-Level:
X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSMEkh4S8sAC for <hybi@ietfa.amsl.com>; Mon, 18 Apr 2016 18:13:34 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5605412D963 for <hybi@ietf.org>; Mon, 18 Apr 2016 18:13:34 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 1AD9618000F; Mon, 18 Apr 2016 18:13:05 -0700 (PDT)
To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160419011305.1AD9618000F@rfc-editor.org>
Date: Mon, 18 Apr 2016 18:13:05 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/hybi/Z28g3GO6GGAEzkU374xGFv4NerY>
X-Mailman-Approved-At: Mon, 18 Apr 2016 19:14:15 -0700
Cc: rfc-editor@rfc-editor.org, hybi@ietf.org, a.dunaev@nplab.ru
Subject: [hybi] [Technical Errata Reported] RFC6455 (4672)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 19 Apr 2016 01:13:35 -0000
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 <a.dunaev@nplab.ru> 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
- [hybi] [Technical Errata Reported] RFC6455 (4672) RFC Errata System