Hello,
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
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.
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.
Thanks,
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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf