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