Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Mykyta Yevstifeyev <> Tue, 12 July 2011 04:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1628C21F8F42; Mon, 11 Jul 2011 21:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.493
X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RXN8qlz6ib01; Mon, 11 Jul 2011 21:40:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B984721F8F3C; Mon, 11 Jul 2011 21:40:09 -0700 (PDT)
Received: by fxe4 with SMTP id 4so5757106fxe.27 for <multiple recipients>; Mon, 11 Jul 2011 21:40:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+1Eih9ROKdXmiPP4U7A1oEHgSHH9POku0zrYcidWreQ=; b=wOf2y+ruSoLU+5eg1m48o+W/uaaRnHIaxNI24TsqP0AKWz2BtuAnvXgozms6BY2U+h Z3zh7TMDZ1uk9Bt3fxUh3qaCUYlVnybchUTZEcXzlMnOHw1RjWo813LMSWMNUztZ2U2F yc8K85Xf6J0V209OaAxr+aUtKRftJGArTJDHk=
Received: by with SMTP id c2mr8746584fac.35.1310445608634; Mon, 11 Jul 2011 21:40:08 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id n27sm9663985faa.4.2011. (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 21:40:07 -0700 (PDT)
Message-ID: <>
Date: Tue, 12 Jul 2011 07:40:52 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 11 Jul 2011 23:36:45 -0700
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2011 04:40:11 -0000


I'd like to comment the draft-ietf-hybi-thewebsocketprotocol-10, which 
is currently in IETF Last Call.

Throughout the document:

>     _This section is non-normative._

are quite unusual.  Such statements occur at the beginning of 
Introduction, which is meant to be nob-normative a priori, its 
subsections, and Section 4.7, Examples.  These sections, IMO, doesn't 
need to be additionally marked as non-normative.

Section 2.1 makes use of a bit unusual notation; explicitly, it often 
excludes possibility to reference ABNF productions in angle brackets in 
the text.  I don't object to the existing notation (but see below), but 
ABNF rules should be referenced in other way.

Section 3.  I propose to rewrite the first paragraph as follows:

>     This specification defines two URI schemes for WebSocket protocol -
>     'ws' and 'wss'.  Their syntax is defined below using ABNF [RFC5234]
>     in the<ws-uri>  and<wss-uri>, respectively:
>       ws-uri  = "ws:" "//" host [ ":" port ] path-abempty [ "?" query ]
>       wss-uri = "wss:" "//" host [ ":" port ] path-abempty [ "?" query ]
>     where the<host>,<port>,<path-abempty>  and<query>  rules are
>     defined in RFC 3986 [RFC3986].

Rationale: (1) The first paragraph gets clearer. (2) ABNF is changed not 
ot use pros-vals (RFC 5234) (3) s/path/path-abempty/ to directly import 
it from RFC 3986 (4) Several editorial issues fixed.

I see a number of times the term "WebSocket URI" is used in the draft.  
I would be useful to clarify that the "WebSocket URI" is either a valid 
'ws' or 'wss' URI.

Section 4.2.  I have a concern with usage of ABNF here.  Let's see:

>     frame-fin               = %x0 ; more frames of this message follow
>                             / %x1 ; final frame of this message

Looking at RFC 5234, Section 2.3 we find:

>     Rules resolve into a string of terminal values, sometimes called
>     characters.

Which means that ABNF represents characters only; no bits may be 
represented by it.  Creating the normative and formal definition of a 
header is just impossible.  The above rule will be correctly interpreted as:

>     frame-fin               =<ASCII NUL character 0x00>
>                             /<ASCII SOH character 0x01>

which isn't what you mean.  Changing "x" to "d" to represent binary 
values won't help, since all other bits will be considered to be zeros 
and the result will be the same.  Conclusion: there is no other way 
other that to remove the ABNF definition of WS message here.

Sections 4.5.2. and 4.5.3.  I think the names "ping" and "pong" can 
better be replaced with "echo request" and "echo response".

Section 5.2.2, bullet 3, sub-bullet 4.  When defining the ABNF for a 
header, the header name should be included in it as well.  So the first 
line should be:

> sec-websocket-accept-header = "Sec-WebSocket-Accept:" base64-value

This will also deal with the issue regarding the name of ABNF production 
for the header.

Section 9.1:

>           extension-token = registered-token / private-use-token

If you want RFC 2616 ABNF, this should be changed to:

>           extension-token = registered-token | private-use-token


>           Sec-WebSocket-Extensions: bar; baz=2
>     is exactly equivalent to
>           Sec-WebSocket-Extensions: foo, bar; baz=2

These two examples don't match the aforementioned ABNF; the space before 
"baz=2" should be removed.

Section 11.1:

> 11.1.  Registration of "ws:" Scheme

The ":" colon isn't included in the scheme name.  So replacing "ws:" 
with 'ws' should be OK.

>     A |ws:| URI identifies a WebSocket server and resource name.

In Section 2.1 you mentioned that |foo| is used when "foo" is a header.  
Please use simple quotes.

>        In ABNF terms using the terminals from the URI specifications:
>        [RFC5234] [RFC3986]
>             "ws" ":" hier-part [ "?" query ]

This isn't what you described in Section 3. <hier-part> includes the 
<userinfo> part, which shouldn't be present in WebSocket URIs.  This 
ABNF should be fixed to match one in Section 3.

>        The<path>  [RFC3986] and<query>  components form the resource name
>        sent to the server to identify the kind of service desired.  Other
>        components have the meanings described in RFC3986.

If you adopt my proposal to Section 3, this should be fixed in the same way.

>     References.
>        RFC XXXX

References here mean (from RFC 4395):

>     References.
>        Include full citations for all referenced documents.  Registration
>        templates for provisional registration may be included in an
>        Internet Draft; when the documents expire or are approved for
>        publication as an RFC, the registration will be updated.

So this field should refer to Section 14 of the draft.

Section 11.2: the same applies.

Section 11.12:

>        Version Number  | Reference
>      -+----------------+-----------------------------------------+-
>       | 0              + draft-ietf-hybi-thewebsocketprotocol-00 |
>      -+----------------+-----------------------------------------+-
>         [ . . . ]
>      -+----------------+-----------------------------------------+-
>       | 9              + draft-ietf-hybi-thewebsocketprotocol-09 |
>      -+----------------+-----------------------------------------+-

This looks very strange, since all revisions of the draft will become a 
single RFC.  I propose:

>        Version Number  | Reference
>      -+----------------+-----------------------------------------+-
>       | 1              + This document                           |
>      -+----------------+-----------------------------------------+-

Moreover, what is the allowed range of version numbers (and all other 
values for which the registries are created)?  What entries are 
Unassigned and what are Reserved (I suppose 0 might be Reserved, others 
- Unassigned).

I find the only 2 definitions of syntax of header field described in 
your document - Sec-WebSocket-Accept and Sec-WebSocket-Extensions.  
Where are the other syntax definitions for those header fields 
registered in Section 11?

References.  RFC 3490 is a downward reference here; RFC 3967 procedure 
should have been used.  All other of them seem OK.

I hope my comments were useful.

Mykyta Yevstifeyev

11.07.2011 17:02, The IESG wrote:
> The IESG has received a request from the BiDirectional or
> Server-Initiated HTTP WG (hybi) to consider the following document:
> - 'The WebSocket protocol'
>    <draft-ietf-hybi-thewebsocketprotocol-10.txt>  as a Proposed Standard