Subject: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt

From: [email-masked]
Date: Wed, 08 Jun 2011 10:30:12 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF.

    Title         : The WebSocket protocol
    Author(s)     : I. Fette
    Filename      : draft-ietf-hybi-thewebsocketprotocol-08.txt
    Pages         : 68
    Date          : 2011-06-08
    
   The WebSocket protocol enables two-way communication between a client
   running untrusted code running in a controlled environment to a
   remote host that has opted-in to communications from that code.  The
   security model used for this is the Origin-based security model
   commonly used by Web browsers.  The protocol consists of an opening
   handshake followed by basic message framing, layered over TCP.  (In
   theory, any transport protocol could be used so long as it provides
   for reliable transport, is byte clean, and supports relatively large
   message sizes.  However, for this document, we consider only TCP.)
   The goal of this technology is to provide a mechanism for browser-
   based applications that need two-way communication with servers that
   does not rely on opening multiple HTTP connections (e.g. using
   XMLHttpRequest or <iframe>s and long polling).

   Please send feedback to the [email-masked] mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Jun 2011 08:26:03 +1000

> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt

best viewed at http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08
 with diff tools etc.

---

From: Anthony Catel <[email-masked]>
Date: Thu, 09 Jun 2011 00:41:03 +0200

Hi,

           ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
           wss-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]

Should be

           ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
           wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

Le 09/06/2011 00:26, Greg Wilkins a écrit :
> On 9 June 2011 03:30,<[email-masked]>  wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Jun 2011 09:03:37 +1000

Wow - that was a more extensive rewrite than I was expecting - but
most of the text looks to be good improvements - good work!

However 4.2 says

     The payload data is defined as extension data concatenated wit
application data.

and this is reflected elsewhere in the document.   Concatenation is
not the correct paradigm as this prohibits a compression or encrypting
extension which changes the entire payload.
I think we should simply say that the payload data is the application
data as processed by all the negotiated extensions.

Section 4.4, bullet point 3 is formatted as a bullet point, when it is
really a sub clause of the previous bullet point.  Also the Note about
control frames is formatted as another bullet point.

I also think this section needs another point like:

  * The fragments of one message may not be interleaved between the
fragments of another message unless an extension has been negotiated
that can interpret the interleaving.

4.8 says:

   o  Extension data may be placed in the payload data before the
      application data.

As above, this prevents compression/encrypting extensions.  Extensions
must be allowed to arbitrarily mutate the application data.

9.2.1 Compression

I still maintain that this extension should not be supported - it
breaks all the rules the spec defines for extensions - specifically it
mutates the framing.   There is an alternative compression proposal
available for in frame compression that would comply with the rules of
extensions (assuming we remove the concatenation restriction above).

In section 10, the draft says:

   The biggest security risk when sending text data using this protocol
   is sending data using the wrong encoding.  If an attacker can trick
   the server into sending data encoded as ISO-8859-1 verbatim (for
   instance), rather than encoded as UTF-8, then the attacker could
   inject arbitrary frames into the data stream.

I don't think this is true - not since we dropped sentinel encoded frames.
Length encoded frames are safe to send arbitrary data and there is no
possibility of any payload being interpreted as a frame in the
datastream.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 8 Jun 2011 16:13:27 -0700

>          wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
Sigh, will fix. There may be a -09 in a day or two I suspect ;-)

>> best viewed at
>> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08
>>  with diff tools etc.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 8 Jun 2011 16:23:57 -0700

> extension which changes the entire payload.

Not really. We used to say the "body" of the frame was extension data
followed by application data, indeed the payload len has always meant
len(ext)+len(app). This re-write takes a lot of the sections that used to
talk about this and now just talks about "payload" where payload data is
extension data followed by application data, just as before. It doesn't
prevent a compressing or encrypting extension -- the extension is free to
modify the application data. [perhaps that point needs to be called out more
explicitly somewhere]. For instance, a compressing extension could have a
small amount of "extension data" such as an instruction to reset state and
contain "application data" (the compressed data).

> data as processed by all the negotiated extensions.
I think I would prefer to to keep some distinction of what data is purely
for the extensions and what data is the actual data being passed by the
protocol, at least conceptually. We can make it clearer that the extensions
modify payload data, and at some points the distinction may not be crystal
clear, but I think the distinction is still useful (for instance, by saying
that a pong must have identical application data, we don't have to say that
the payload is identical.)

> control frames is formatted as another bullet point.

yes, sorry

> that can interpret the interleaving.

anyone else have thoughts here? it seems reasonable to me but I'd like to
hear other opinions.

> must be allowed to arbitrarily mutate the application data.

see prior explanation earlier in this response

> extensions (assuming we remove the concatenation restriction above).
How do others feel about keeping it / yanking it?

> possibility of any payload being interpreted as a frame in the

I agree the text needs to be changed, but perhaps rather than killing it
entirely, it can be rewritten as a more general statement of please be
careful with encodings, as when you tell a recipient something is utf-8,
they may make assumptions that will prove problematic if you send them
something like iso-8859-1 instead, or at the least may cause
misinterpretation or loss of data.

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 8 Jun 2011 23:28:07 +0000

About compression: Greg already expressed this feeling on the mailing list and there was very strong opposition.
At this point, I’d rather we not make such big changes. Let’s limit 09 to nits and typos.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ian Fette (????????)
Sent: Wednesday, June 08, 2011 16:24
To: Greg Wilkins
Cc: [email-masked]
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt

On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins <[email-masked]<mailto:[email-masked]>> wrote:
Wow - that was a more extensive rewrite than I was expecting - but
most of the text looks to be good improvements - good work!

However 4.2 says

Not really. We used to say the "body" of the frame was extension data followed by application data, indeed the payload len has always meant len(ext)+len(app). This re-write takes a lot of the sections that used to talk about this and now just talks about "payload" where payload data is extension data followed by application data, just as before. It doesn't prevent a compressing or encrypting extension -- the extension is free to modify the application data. [perhaps that point needs to be called out more explicitly somewhere]. For instance, a compressing extension could have a small amount of "extension data" such as an instruction to reset state and contain "application data" (the compressed data).

I think I would prefer to to keep some distinction of what data is purely for the extensions and what data is the actual data being passed by the protocol, at least conceptually. We can make it clearer that the extensions modify payload data, and at some points the distinction may not be crystal clear, but I think the distinction is still useful (for instance, by saying that a pong must have identical application data, we don't have to say that the payload is identical.)

yes, sorry

anyone else have thoughts here? it seems reasonable to me but I'd like to hear other opinions.

4.8 says:

9.2.1 Compression

I agree the text needs to be changed, but perhaps rather than killing it entirely, it can be rewritten as a more general statement of please be careful with encodings, as when you tell a recipient something is utf-8, they may make assumptions that will prove problematic if you send them something like iso-8859-1 instead, or at the least may cause misinterpretation or loss of data.

_______________________________________________
hybi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Jun 2011 09:53:37 +1000

2011/6/9 Ian Fette (イアンフェッティ) <[email-masked]>:

> protocol, at least conceptually.

Fair enough, but I do think that we need to call out that extensions
may also mutate the application data.

cheers

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Jun 2011 02:22:10 +0200

* Gabriel Montenegro wrote:
>About compression: Greg already expressed this feeling on the mailing
>list and there was very strong opposition. At this point, I’d rather we 
>not make such big changes. Let’s limit 09 to nits and typos.

I don't care much about the next draft, but at some point we'll need a
draft that addresses the known issues, so we can then have a working
group last call to be sure that that the known issues have indeed been
addressed so we can then ask the IESG to consider the document for pub-
lication. When should we make the big changes to compression so we can
move forward on that issue?

(It is possible you might mean that the next draft is meant as just a
bit of polish as last step before an IETF Last Call, so we are really
past a point where we would consider "big changes". I do not believe
that is the case, we haven't, for instance, been getting any comments
from the W3C who work on the browser API for Websockets, on the
document, that I've seen anyway; and I haven't done any review in April
when you announced a Last Call myself, since we still had to make "big
changes" like to compression at that point. Overall, there has been a
distinct lack of review of the document so far. Greg Wilkins noted he
found the Last Call premature. I very much agree.)

As an aside, I am not aware of any opposition to address the security
concerns I noted with respect to `deflate-stream` back in April.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 8 Jun 2011 17:26:57 -0700

On Wed, Jun 8, 2011 at 5:22 PM, Bjoern Hoehrmann <[email-masked]> wrote:

>From the W3C side, Hixie and I have gone over it and he just published a new
API spec a day or two ago that properly lines up the two documents.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Jun 2011 11:01:51 +1000

> and there was very strong opposition.

I agree that there are strong opinions for and against stream compression.

Typically such division should mean that such a feature should not be
put into the draft.  But unfortunately, as has happened all to often
with this process, the feature was put in without much discussion and
we now have to argue to have it removed.  So the status quo is the
inclusion of a non consensus feature.

I really do not see how we can go forward with an optional feature
that does not have consensus support, that contradicts the rest of the
specification on what an extension is able to do and has some
unresolved security questions about it.

regards

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Jun 2011 03:08:36 +0200

>API spec a day or two ago that properly lines up the two documents.

I think it is good that you help "Hixie" with his editing duties. But we
do need to know if there are any problems with the documents we work on.
I have not seen a representative of the W3C tell us of any problems, or
tell us they reviewed the draft and found no problems. In either case, I
would expect there to be mails in the list archive detailing either, but
I am not aware of, and haven't found when searching, any to this end. If
"Hixie" did provide comments on our documents, I would welcome pointers
to them.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 8 Jun 2011 19:16:56 -0700

> "Hixie" did provide comments on our documents, I would welcome pointers

Hixie is the editor of the HTML spec. He pointed out problems, they were
addressed. I've a series of emails from him that I am happy to share if he
does not mind (there's nothing private in them, but I don't make a habit of
forwarding private correspondence.) As we have the luxury of meeting
face-to-face, there were also face-to-face discussions to resolve stickier
issues, along with a few late night IRC sessions on #whatwg.

Largely the issues were not substantive. The spec has not changed much from
the API perspective, the exception being exposing the extensions that were
negotiated in the handshake via the API, and some semantics around whether
onError() is necessary or not and how that interacts with the WebSocket
Close Status Codes. That has been aligned in his latest spec. The rest was
just "I need hooks for this" e.g. "How do I send data? What is the algorithm
/ section of the spec I reference to send data?".

Finally, I'm not sure what you expect to get from W3C that you're not
getting from the people on this list. You've got the people implementing the
API watching this list, that's the same subset of the people from W3C that
would provide meaningful commentary about the spec.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 9 Jun 2011 12:21:07 +0900

> anyone else have thoughts here? it seems reasonable to me but I'd like to

I think it's good for clarification (though when we read the fragmentation
spec, it's clear that interleaving doesn't work without extension).

It's a small edit.

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Thu, 09 Jun 2011 08:38:43 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt

The diff is really big...

http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-thewebsocketprotocol-08.txt

...I can see it has gotten tidier and more referential to existing TLAs 
but I had a hard time spotting what actually changed implementation-wise 
from -07 protocol.

Is there anything or we just crank the default version number up to 8?

-Andy

---

From: Dirkjan Ochtman <[email-masked]>
Date: Thu, 9 Jun 2011 10:08:40 +0200

> Is there anything or we just crank the default version number up to 8?

It looks like there are at least some differences:

- The extended payload length may now use 64 bits (instead of just 63).
- Invalid client handshake results in HTTP error instead of connection abortion.
- Two new closure status codes (1005 and 1006).
- Specified handling of invalid UTF-8 on the client side.

I note that the remarks from my email (from May 30, [1]) seem to not
have had any impact on this draft. Did my message come to late to make
any changes to this draft, did my suggestions not make sense for
inclusion, or did I perhaps not follow the correct protocol for
suggesting improvements? (I noticed that the required server headers
*are* listed in the section on client acceptance of the server's
opening handshake, but not in the section on the server sending that
handshake.)

Two further questions on things that I feel could be clarified, in draft-08:

- This may be silly, but in the introduction text for the figure
(which is very useful!) in section 4.2, I wonder if it would be
helpful to state explicitly whether the bits are listed in big- or
little-endian order. For bytes, this is defined explicitly in the
descriptions, but I know that I was at least somewhat confused about
this (and got it wrong in my initial implementation). This might just
be my inexperience with diagrams/specs like this, so feel free to
ignore this.

- Section 4.5.1 (about status codes for Close frames) does not mention
anything about masking. I would presume that the status code bytes,
being part of the application data part of the frame, should be
masked, but perhaps it's worth pointing this out explicitly.

Cheers,

Dirkjan

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg07461.html

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Thu, 09 Jun 2011 09:17:55 +0100

On 06/09/2011 09:08 AM, Somebody in the thread at some point said:
> On Thu, Jun 9, 2011 at 09:38, "Andy Green (林安廸)"<[email-masked]>  wrote:

Thanks for the summary.

> - The extended payload length may now use 64 bits (instead of just 63).

Well, that went in the wrong direction then.

> - Invalid client handshake results in HTTP error instead of connection abortion.

Seems important...

> - Specified handling of invalid UTF-8 on the client side.

OK.

> have had any impact on this draft.

Welcome to hybi ^^

-Andy

---

From: Norio Kobota <[email-masked]>
Date: Thu, 09 Jun 2011 18:28:29 +0900

Hello,

I'm confused a little about the following matter.

 > - The extended payload length may now use 64 bits (instead of just 63).

The figure at section 4.2 shows Extended payload length(16/63).
But in text, payload length is 7+64 bits.(MSB==0)

Am I correct though I understood as follows?

1.extended payload length 'field' has 64 bit length.
2.but most significant bit must be 0.
3.so, the max size of extended payload length is equal to
   INT64_MAX(0x7fffffffffffffffLL)

Sincerely,

Nori

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 9 Jun 2011 19:06:13 +0900

> But in text, payload length is 7+64 bits.(MSB==0)

Values written after each field in Section 4.2 are the number of bits each
field occupies. Extended payload field occupies 64 bits but still can hold
only value <= 0x7fffffffffffffff.

It may be a bit confusing that the diagram is using 63 instead of actual
field length of 64.

> 1.extended payload length 'field' has 64 bit length.

yes

> 2.but most significant bit must be 0.

yes

>  INT64_MAX(0x7fffffffffffffffLL)

yes

---

From: Dirkjan Ochtman <[email-masked]>
Date: Thu, 9 Jun 2011 12:13:14 +0200

>  INT64_MAX(0x7fffffffffffffffLL)

Yes, I got my reading wrong. The new draft removes one mention of the
effective 63-bits limit of the length field, but the mandate for
zeroing the most significant bit is still there.

Cheers,

Dirkjan

---

From: Norio Kobota <[email-masked]>
Date: Thu, 09 Jun 2011 19:17:43 +0900

Thanks!

(2011/06/09 19:06), Takeshi Yoshino wrote:
> On Thu, Jun 9, 2011 at 18:28, Norio Kobota <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Values written after each field in Section 4.2 are the number of bits
> each field occupies. Extended payload field occupies 64 bits but still
> can hold only value <= 0x7fffffffffffffff.
>

---

From: Denis Lagno <[email-masked]>
Date: Thu, 9 Jun 2011 14:18:51 +0400

Draft specifies that ABNF for value of "Sec-WebSocket-Protocol" field
is 1#token.
First nit is that looking at definition of # rule in RFC2616 it
specifies that 1#token can contain Linear White Space, and LWS can
contain CRLF; I guess CRLF in subprotocols list is not expected?
Second nit is that it is not ABNF, ABNF RFC does not contain # rule.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 9 Jun 2011 19:20:33 +0900

Some more minor but non trivial changes I can name are

08: Solicited pong must have the same application data as ping
07: Solicited pong must have the same payload as ping

08: without any extension, receiver ignores RSV1-3 even if turned on
07: not specified

08: without any extension, receiver ignores frames with unknown opcode
07: not specified

08: Client -> server Sec-WebSocket-Protocol ABNF is 1#token
07: Client -> server Sec-WebSocket-Protocol ABNF is 1#(token |
quoted-string)

08: Server -> client Sec-WebSocket-Protocol ABNF is (token)
07: not explicitly specified

On Thu, Jun 9, 2011 at 16:38, "Andy Green (林安廸)" <[email-masked]> wrote:

> ...I can see it has gotten tidier and more referential to existing TLAs but
> I had a hard time spotting what actually changed implementation-wise from
> -07 protocol.
>

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Thu, 09 Jun 2011 11:28:03 +0100

On 06/09/2011 11:20 AM, Somebody in the thread at some point said:

Hi -

> 07: Solicited pong must have the same payload as ping

This is already done like that in libwebsockets fwiw.

> 08: without any extension, receiver ignores RSV1-3 even if turned on

OK it kills the connection right now, important.

> 08: without any extension, receiver ignores frames with unknown opcode

Hm okay at the moment it just blows chunks, this is a better idea.

OK.

> 07: not explicitly specified

Right that is a good change.

Thanks for pointing these out I would definitely miss them otherwise.

-Andy

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 9 Jun 2011 14:10:34 +0300

On 6/9/11 6:21 AM, Takeshi Yoshino wrote:
> On Thu, Jun 9, 2011 at 08:23, Ian Fette (イアンフェッティ)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> I think it's good for clarification (though when we read the
> fragmentation spec, it's clear that interleaving doesn't work without
> extension).
>
> It's a small edit.
>
I agree

/Sal

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Jun 2011 13:22:36 +0200

> Second nit is that it is not ABNF, ABNF RFC does not contain # rule.

"The ABNF for the value of this header is 1#token, where the definitions 
of constructs and rules are as given in [RFC2616]."

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Jun 2011 16:10:27 +0200

>issues, along with a few late night IRC sessions on #whatwg.

When Google employees get together in private, decide to make changes,
and then post a document, without particularily telling the rest of us
what has changed, which issues have been addressed, which issues have
not been addressed, in fact, not even telling us what the issues were,
then that's not open and consensus-based vendor-independent standards
development.

>would provide meaningful commentary about the spec.

The hybi charter requires the working group to consider any concerns
raised by the W3C. I expect people from the IESG or the community at
large will ask whether this has been done, and the easy way to answer
would be showing them records of the W3C confirming they have reviewed
the document and any issues they had have been addressed to their sa-
tisfaction.

Arguing, instead, that we seem to have all the right people involved,
so such formalities are unnecessary, while at the same time people on
the list are working together to figure out what changes have been made
in the latest draft, would not be much of an answer to such questions.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 9 Jun 2011 15:44:56 +0000

That review and perhaps others sent to hybi happened in the context of the call made for w3c feedback. Please see:

http://lists.w3.org/Archives/Public/public-ietf-w3c/2011Mar/0002.html

Further discussion in the context of the joint W3C/IETF conference call:
http://lists.w3.org/Archives/Public/public-ietf-w3c/2011Apr/0000.html

thanks,

Gabriel

> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:[email-masked]]
> Sent: Thursday, June 09, 2011 07:10
> To: [email-masked]
> Cc: [email-masked]; Gabriel Montenegro
> >Hixie is the editor of the HTML spec. He pointed out problems, they
> >were addressed. I've a series of emails from him that I am happy to
> >share if he does not mind (there's nothing private in them, but I don't
> >make a habit of forwarding private correspondence.) As we have the
> >luxury of meeting face-to-face, there were also face-to-face
> >discussions to resolve stickier issues, along with a few late night IRC sessions
> on #whatwg.
> 
> When Google employees get together in private, decide to make changes, and
> then post a document, without particularily telling the rest of us what has
> changed, which issues have been addressed, which issues have not been
> addressed, in fact, not even telling us what the issues were, then that's not open
> and consensus-based vendor-independent standards development.
> 
> >getting from the people on this list. You've got the people
> >implementing the API watching this list, that's the same subset of the
> >people from W3C that would provide meaningful commentary about the spec.
> 
> The hybi charter requires the working group to consider any concerns raised by
> the W3C. I expect people from the IESG or the community at large will ask
> whether this has been done, and the easy way to answer would be showing
> them records of the W3C confirming they have reviewed the document and any
> issues they had have been addressed to their sa- tisfaction.
> 
> Arguing, instead, that we seem to have all the right people involved, so such
> formalities are unnecessary, while at the same time people on the list are
> working together to figure out what changes have been made in the latest draft,
> would not be much of an answer to such questions.
> --

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 11 Jun 2011 07:32:30 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt

Typo in page 15:

          host = <host, defined in [RFC3986], Section 3.2.2>
          port = <host, defined in [RFC3986], Section 3.2.3>
          path = <path-abempty, defined in [RFC3986], Section 3.3>
          query = <query, defined in [RFC3986], Section 3.4>

It should be:

          host = <host, defined in [RFC3986], Section 3.2.2>
          port = <port, defined in [RFC3986], Section 3.2.3>
          path = <path-abempty, defined in [RFC3986], Section 3.3>
          query = <query, defined in [RFC3986], Section 3.4>

(note the "port" line).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 11 Jun 2011 07:49:01 +0200

> Second nit is that it is not ABNF, ABNF RFC does not contain # rule.

Page 12 says:

   if Example Corporation were to create a Chat subprotocol to
   be implemented by many servers around the Web, they could name it
   "chat.example.com".  If the Example Organization called their
   competing subprotocol "example.org's chat protocol", then the two
   subprotocols could be implemented by servers simultaneously

Of course "example.org's chat protocol" is not a valid token according
to RFC 2616 grammar:

  CHAR           = <any US-ASCII character (octets 0 - 127)>
  token            = 1*<any CHAR except CTLs or separators>

So there are two options:

1) Make Sec-WebSocket-Protocol grammar 1#token (as defined now). In
this case protocol values MUST be token (no quoted strings, neither
separators). Then fix example in page 12.

2) Make Sec-WebSocket-Protocol grammar as follows:   1#( quoted-string | token )
In this way both examples in page 12 are valid.

I strongly prefer option 1 (I don't consider that spaces or UTF'8
multibyte symbols are needed for naming a protocol).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 11 Jun 2011 07:56:26 +0200

> then that's not open and consensus-based vendor-independent standards

I've repeated many times in this maillist: please, add a fuxxxxx
Changelog section in the draft.
Revision 76+8 of the draft, and no Changelog section. And here the
problems. Will the authors ignore it again?

A Changelog section should be a MUST in any new revision.

PS: A diff is not a changelog.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 14 Jun 2011 15:02:34 +0900

>  token            = 1*<any CHAR except CTLs or separators>
I think this paragraph should be fixed by adding 'by using "chat.example.org"
for their subprotocol name' right after "example.org's chat protocol".
Maybe, that's what the editor originally wanted this text to mean.

> separators). Then fix example in page 12.

I prefer 1) too.

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 14 Jun 2011 15:12:40 +0900

Sorry, this just has been addressed by -09.

Takeshi

On Tue, Jun 14, 2011 at 15:02, Takeshi Yoshino <[email-masked]> wrote:

> I think this paragraph should be fixed by adding 'by using "
> chat.example.org" for their subprotocol name' right after "example.org's
> chat protocol". Maybe, that's what the editor originally wanted this text to
> mean.
>
>