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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]