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

Julian Reschke <julian.reschke@gmx.de> Tue, 12 July 2011 06:59 UTC

Return-Path: <julian.reschke@gmx.de>
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 8AEFD21F9165 for <hybi@ietfa.amsl.com>; Mon, 11 Jul 2011 23:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.355
X-Spam-Level:
X-Spam-Status: No, score=-104.355 tagged_above=-999 required=5 tests=[AWL=-1.756, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi8XU+icuQrY for <hybi@ietfa.amsl.com>; Mon, 11 Jul 2011 23:59:53 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7FF6921F8DD0 for <hybi@ietf.org>; Mon, 11 Jul 2011 23:59:52 -0700 (PDT)
Received: (qmail invoked by alias); 12 Jul 2011 06:59:46 -0000
Received: from p508FD648.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.214.72] by mail.gmx.net (mp007) with SMTP; 12 Jul 2011 08:59:46 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18F9GxhqW8FBGM+958RZE27y0PuirBeCVNv0s03Hl mcghBhIN9/bezN
Message-ID: <4E1BF0D6.4090702@gmx.de>
Date: Tue, 12 Jul 2011 08:59:34 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <4E1BD054.7010103@gmail.com>
In-Reply-To: <4E1BD054.7010103@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: hybi@ietf.org, ietf@ietf.org, draft-ietf-hybi-thewebsocketprotocol@tools.ietf.org
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 12 Jul 2011 06:59:53 -0000

On 2011-07-12 06:40, Mykyta Yevstifeyev wrote:
> ...
> 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.
> ...

+1

> 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.

-10

Granted, it doesn't use prose values anymore, but then it get's 
incomplete. I believe putting references to ABNF productions from other 
specs into prose values is absolutely the right thing to do (as opposed 
to just mention them in prose).

> 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:
> ...

Why?

> Section 9.1:
>
>> extension-token = registered-token / private-use-token
>
> If you want RFC 2616 ABNF, this should be changed to:
> ...

yes.

>> extension-token = registered-token | private-use-token
>
> Ibid:
>
>> 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.
 > ...

They do, as the RFC 2616 ABNF allows implied Linear Whitespace.

That being said, it might be a good idea to revisit the choice of 
syntax, or at least to clarify the LWS situation.

>> 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.

...or removed. Why are there two?

>> 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 14 of this document".

> 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 is indeed fishy and I would be really surprised if IESG and RFC 
Editor let this pass.

If 0..9 can't be reassigned then let's just state they are reserved.

> ...

Best regards, Julian