The WebSocket Protocol
draft-ietf-hybi-thewebsocketprotocol-17

[Ballot discuss]
The Gen-ART Review by Richard Barnes was updated to cover the -13
  version of this document.  The updated review can be found at:
  http://www.ietf.org/mail-archive/web/hybi/current/msg08683.html.

  The -13 version of the document seems to be better than the earlier
  version, but there are two concerns that need further discussion:

  1. The browser must be prepared to buffer effectively infinite data,
  either from a single frame of 2**64 octets or from a single frame of
  unlimited fragments.

  The text proposed by Alexey resolves this part of my DISCUSS.

  2. The masking technique is trivially circumvented and firewalls must
  undergo significant update to inspect essentially plaintext content
  that will now be carried on ports 80 and 443.

  This point is still being talked about on the WG mail list.  I will clear
  once there is consensus.

[Ballot discuss]
The Gen-ART Review by Richard Barnes was updated to cover the -13
  version of this document.  The updated review can be found at:
  http://www.ietf.org/mail-archive/web/hybi/current/msg08683.html.

  The -13 version of the document seems to be better than the earlier
  version, but there are two concerns that need further discussion:

  1. The browser must be prepared to buffer effectively infinite data,
  either from a single frame of 2**64 octets or from a single frame of
  unlimited fragments.

  The text proposed by Alexey resolves this part of my DISCUSS.

  2. The masking technique is trivially circumvented and firewalls must
  undergo significant update to inspect essentially plaintext content
  that will now be carried on ports 80 and 443.

  This point is still being talked about on the WG mail list.  I will clear
  once there is consensus.

[Ballot discuss]


This draft contains a normative reference to IDNA2003.  While progressing other drafts through the IESG gauntlet something along the lines of the following was said "referring to IDNA2003 normatively is going to be a show stopper" and "IDNA2008 is the go-forward technology".  Has the thinking changed?  And, can I use the same magic pixie dust you're using to refer to IDNA2003 when I progress other non-Apps drafts in the future?



addressed





#1) cleared

#2) cleared

[Ballot comment]
Sec 1.6, p11, last para: Maybe add a reference to http://www.w3.org/TR/XMLHttpRequest/ so people can find where Sec- headers aren't supposed to be set.

Sec 5.2: FIN: whether 0 or 1 indicates the final fragment is in ABNF, but it would help to have it in the prose when the field is first introduced.

Sec 14.1: addressed

[Ballot discuss]


This draft contains a normative reference to IDNA2003.  While progressing other drafts through the IESG gauntlet something along the lines of the following was said "referring to IDNA2003 normatively is going to be a show stopper" and "IDNA2008 is the go-forward technology".  Has the thinking changed?  And, can I use the same magic pixie dust you're using to refer to IDNA2003 when I progress other non-Apps drafts in the future?



Shouldn't the RFC 3490 DOWNREF have been called out in the IETF LC?  The WGLC on April 24, referred to fixing all IDNITS, but not the downref to RFC 3490.





#1) cleared

#2) cleared

[Ballot comment]
Section 1 has lots of "_This section is non-normative._" That convention isn't defined until section 2, so it's pretty silly to see them in section 1. But even so, I don't think it clears up anything. I would prefer to remove them.

4.1 - "Additionally, if the client is a web browser, an /origin/ MUST be supplied." Also see sub-bullet 8 of the handshake: "The request MUST include a header field with the name "Origin" [I-D.ietf-websec-origin] if the request is coming from a browser client." What happens if a web browser doesn't supply an origin? And how would you know if a web browser didn't do this? (That is, how can you distinguish it from a non-web browser?) I don't see how this can be a MUST.

4.1 - "In a Web browser context, the client SHOULD consider the number of tabs the user has open in setting a limit to the number of simultaneous pending connections." That's going to end up being anachronistic. Let's not put SHOULDs on this kind of user interface stuff. How about instead, "For example, in a web browser context, the number of open windows or tabs are a good indication of the number of simultaneous connections."

4.2 - "_This section only applies to servers._" Seems unnecessary.

4.3 - Do you really intend base64-value (and therefore Sec-WebSocket-Key and Sec-WebSocket-Accept) to be able to be empty in the ABNF?

5.5 - "A response to an unsolicited pong is not expected." SHOULD/MUST NOT be sent?

5.7 - I don't think "_This section is non-normative._" is necessary. Further, this section seems oddly out of place. Perhaps in an appendix?

[Ballot comment]
Sec 1.6, p11, last para: Maybe add a reference to http://www.w3.org/TR/XMLHttpRequest/ so people can find where Sec- headers aren't supposed to be set.

Sec 5.2: FIN: whether 0 or 1 indicates the final fragment is in ABNF, but it would help to have it in the prose when the field is first introduced.

Sec 14.1: Any reason to not point to FIPS 180-3?

[Ballot discuss]


This draft contains a normative reference to IDNA2003.  While progressing other drafts through the IESG gauntlet something along the lines of the following was said "referring to IDNA2003 normatively is going to be a show stopper" and "IDNA2008 is the go-forward technology".  Has the thinking changed?  And, can I use the same magic pixie dust you're using to refer to IDNA2003 when I progress other non-Apps drafts in the future?



Shouldn't the RFC 3490 DOWNREF have been called out in the IETF LC?  The WGLC on April 24, referred to fixing all IDNITS, but not the downref to RFC 3490.





#1) I'm sure you the WG addressed this, but it would be great if the hash could support something other than SHA-1 for the Sec-WebSocket-Key.  I assume you've linked this in some way to the protocol's version # so that websocket++ can support SHA-256, etc.

#2) Sec 4.2: Should the ABNF for the frame-rsv* be something like:

  frame-rsv*        = %x0
                            / %x1

to allow for the possibility of a "1" value?  Doesn't the current ABNF only allow "0"?

[Ballot discuss]
(1) It seems like there should be more of an explicit statement about what's advisable for an application to do if setting up and using a WebSocket connection fails.  For instance, is it then acceptable for them to fall back to RFC 6202 techniques, if those might work for them?

(2) Was there an intention to "Update" RFC 2616?  Based on the document and the IETF list discussion, I got the impression that the answer is definitely "no", but it doesn't seem like there's much (or any) discussion in the document about the relation between this and 2616.  Since this is using some of the 2616 behavior to get rolling, but makes some additions to it, and then has a totally different flavor afterwards, it seems like a fair question, and it wasn't clear if the working group thought about it.

[Ballot comment]
1) At the next to last bullet in the list of fragmentation rules in section 5.4, can you make it clearer that an
intermediary that might fragment a frame will always be able to tell that whether or not extensions have
been negotiated? In particular, consider calling out that an intermediary that isn't able to see the server's
handshake message (due to it being inside a TLS tunnel for example) also would not "see" individual frames,
so it wouldn't be possible for it to try to fragment them. If the assumption in my first question isn't true, then a
more aggressive adjustment to the text is probably needed.

2) The text in section 5.5.2 (Ping) could be misinterpreted to require sending a Pong even after receiving a Close (otherwise it violates that MUST).

3) There are currently three ways to say this frame has 5 octets of data. Please consider adding a requirement to use the shortest of those three possible ways. (This is related to one of Stephen's discuss points).

[Ballot comment]
A couple of reference issues:


  ** Downref: Normative reference to an Informational RFC: RFC 2818

  ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)

[Ballot comment]
- p20: code "running on www.example.com" is an odd phrase, I think
you mean code "running that was downloaded from www.example.com"

- p27: referring to "Paragraph 4 of Section 4.2.2" from within 4.2.2
is odd and probably wrong depending on how you count paragraphs.
Suggest rewording.

- p29: If the ABNF and the introductory text in 5.2 were to be in
conflict, which takes prededence? I'm not saying there is a
conflict, but that kind of thing happens, so picking one as
normative might be useful just in case.

- p30: the "%x" notation is odd - why not just specify the values in
decimal? If you prefer hex, I'd find 0x8 clearer than %x8.

- p30: you don't say until 5.5 that opcodes 8-10 are control frames,
but you depend on that in 5.4 where you say "control frames MAY be
injected...". Better to move the text at the start of 5.5 earlier.

- p33: why does "to be defined later" appear here? (twice) That
chunk of ABNF seems a bit flakey since all four frame-*-*-data are
just the same binary stuff.

- p33: I guess masking is pretty useless if TLS is in use
end-to-end, but is still done even with TLS in case the TLS
endpoints aren't the websocket endpoints. Is that right? If so, it
might be worth pointing out.

- p36: why no ABNF for control frames?

- p38: "A response to an unsolicited pong is not expected." seems
vague. Can't you not say what MUST or MUST NOT happen?

- p44: Providing some reference for the "Certain algorithms and
specifications..." mentioned in 7.1.7 would be good. (Same comment
for 7.2.1 & 7.2.2)

typos:

- p21: s/doesn't contains/doesn't contain/
- p23: s/a "Origin"/an "Origin"/
- p27: s/other section of/other sections of/
- p36: s/if streaming API/if a streaming API/
- p39: s/base protocols/base protocol/
- p50: s/other section of/other sections of/
- p52: s/in a case of/in the case of/
- p54: s/,TLS authentication./ or TLS authentication./ in 10.5
- p69: s/didn't necessarily endorsed/don't necessarily endorse/

[Ballot discuss]
First one's a "discuss discuss", the others should I hope be fairly
easily handled.

(0) p23: There is no version negotiation here, right? What happens
if the masking algorithm turns out to be problematic or some other
protocol bug needs fixing and a new version of this protocol is
needed - how will clients and servers get updated to a new version
without a flag-day? (Given that not all clients will be downloaded
scripts.)

(1) p20: Are the new header field names case sensitive? That is,
would "sec-wEBSocket-kEY" be ok? I guess so, but saying that (maybe
by saying that the rules from 2616, section 4.2 apply?) would be
good.  Not sure where best to put that text.

(2) p21: I guess if the request includes other things like cookies
or Authorization header fields, then those MUST be processed the
same way that a HTTP server handles them. I think you should say
that if it's true, and even if it's only definitely true if no
websockets extensions are used.

(3) p21: Do you also need to say which optional HTTP header fields
MUST be supported by a websockets server? (Or, is there a general
get-out-of-jail sentence somewhere that says that a server MUST do
all the things a web server can do?) I'm not trying to insist on an
exhaustive list which I guess might be controversial, but the more
you can say here, presumably the more that interop will be improved?

(4) p23: this says the version MUST be 8, earlier it said the client
MUST send 13 - is that a (discuss-grade:-) typo or am I confused?

(5) p24, "If the server supports encryption..." Why is TLS not a
MUST-implement here? I think TLS should be mandatory to implement
for both clients and servers, which needs to be stated, and then the
text here might say "If the server has TLS turned on..." or
something like that. I could live with a SHOULD implement, if
there's a good reason for that, but I'd expect that MUST implement
would be ok for this. Note that I'm not asking for "MUST use" and,
given your definition of client and server is fairly loose, I'd
imagine this ought be painless.  And a related point on p55 - WSC
actually only says what are *not* considered strong algorithms. Why
not reference the MTI ciphersuite from TLS 1.2 here and be done with
it?

(6) p30/31: Is it required to use the minimum number of bytes to
encode the payload length? E.g. could I use the 127-case for a
payload of of 8 or 8000 bytes?  (Also, you only specify that the MSB
of the length field MUST be 0 for the 127-case. Is that correct? Put
another way, if the payload length is 65535 exactly, can I use the
126-case with 0xffff as the value? I guess yes, but just checking.)

(7) p34: how does fragmentation support multiplexing? I don't see
how that works (without extensions). You should say that extensions
are needed for multiplexing if that's the case.

(8) p37: you don't say that a ping frame can have a payload nor
whether that is masked (and similarly for the pong frame application
data).

(9) p53: The attack model in 10.3 is not clearly described, and
while the claim of "provable" security is made, that is not
substantiated, either here or via references. Since this is the
justification for the masking scheme, I think this needs to be
fixed. I suggest removing the "provable" wording, adding an
informative reference to [1] with a strong recommendation to go read
that, and maybe reducing the amount of text in 10.3 since the paper
does a much better job.

  [1] http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf

(10) I think the last call comments about the traffic profile [2]
for websockets being different from HTTP sounds like its worth
including something. While there seems to be controversy about what
to say, I'd hope that some agreed text could be figured out.

  [2] http://www.ietf.org/mail-archive/web/ietf/current/msg69148.html

[Ballot discuss]
The Gen-ART Review by Richard Barnes was updated to cover the -13
  version of this document.  The updated review can be found at:
  http://www.ietf.org/mail-archive/web/hybi/current/msg08683.html.

  The -13 version of the document seems to be better than the earlier
  version, but there are two concerns that need further discussion:

  1. The browser must be prepared to buffer effectively infinite data,
  either from a single frame of 2**64 octets or from a single frame of
  unlimited fragments.

  2. The masking technique is trivially circumvented and firewalls must
  undergo significant update to inspect essentially plaintext content
  that will now be carried on ports 80 and 443.

IANA has a question about one of this document's 15 actions.

First, in the Permanent URI Schemes registry located at:

http://www.iana.org/assignments/uri-schemes.html

a new URI scheme will be registered as follows:

URI Scheme:ws
Description: Websocket server
Reference: [ RFC-to-be ]

Second, in the Permanent URI Schemes registry located at:

http://www.iana.org/assignments/uri-schemes.html

a new URI scheme will be registered as follows:

URI Scheme:wss
Description: Websocket server secure
Reference: [ RFC-to-be ]

Third, in the HTTP Upgrade Tokens registry located at:

http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xml

the registry entry for WebSocket will be made permanent and the
reference will be changed to [ RFC-to-be ].

Fourth, in the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

a new registration will be added as follows:

Header Field Name: Sec-WebSocket-Key
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Fifth, also in the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html\

a new registration will be added as follows:

Header Field Name: Sec-WebSocket-Extensions
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Sixth, IANA will create a new registry for parameters, names and
codepoints for WebSocket. In this new registry there will be a new
subregistry created called the "WebSocket Extension names" registry.

The registration rules for this registry are "First Come First Served"
as defined in RFC5226 with one exception. WebSocket Extension names
whose Extension Identifier matches a private-use-token (values beginning
with "x-"). These Extension Identifiers matching private-use-token are
reserved for Experimental Use as defined by RFC 5226.

There is a single, initial registration in this new registry as follows:

Extension Identifier Extension Common Name Extension Definition Reference
-------------------- ---------------------- ----------------------
-------------
deflate-stream Deflate Stream [ RFC-to-be Section 9.2.1]
[RFC-to-be]

Seventh, in the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html\

a new registration will be added as follows:

Header Field Name: Sec-WebSocket-Accept
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Eighth, also in the Permanent Message Header Field Names registry
located at:

http://www.iana.org/assignments/message-headers/perm-headers.html\

a new registration will be added as follows:

Header Field Name: Sec-WebSocket-Accept
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Ninth, in the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

a new registration will be added as follows:

Header Field Name: Sec-WebSocket-Protocol
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Tenth, in the new registry created in the fifth IANA Action above, a new
registry will be created called the "WebSocket Subprotocol names"
registry. The registration policy for this new subregistry will be
"First Come First Served" as defined by RFC 5226. The registry will
contain the following fields:

- Subprotocol Identifier
- Subprotocol Common Name
- Subprotocol Definition
- Reference

IANA understands that there are no initial entries for this registry.

Eleventh, in the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

a new registration will be added as follows:

Header Field Name: Sec-WebSocket-Version
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Twelfth, in the new registry created in the fifth IANA Action above, a
new registry will be created called the "WebSocket Version Numbers"
registry. The registration policy for this registry is "IETF Review" as
defined by RFC 5226.

--> QUESTION: This section says, "in order to improve interoperability
with intermediate versions published in Internet Drafts, version numbers
associated with such drafts might be registered in this registry." How
can IANA know whether to make such registrations? An I-D can't pass IETF
Review until it's been approved for publication. Should the registration
procedure for this registry be changed to IESG Approval?

The initial registrations in this new registry are:

Version Number Reference
---------------- ------------------------------------------
0 draft-ietf-hybi-thewebsocketprotocol-00
1 draft-ietf-hybi-thewebsocketprotocol-01
2 draft-ietf-hybi-thewebsocketprotocol-02
3 draft-ietf-hybi-thewebsocketprotocol-03
4 draft-ietf-hybi-thewebsocketprotocol-04
5 draft-ietf-hybi-thewebsocketprotocol-05
6 draft-ietf-hybi-thewebsocketprotocol-06
7 draft-ietf-hybi-thewebsocketprotocol-07
8 draft-ietf-hybi-thewebsocketprotocol-08
9 draft-ietf-hybi-thewebsocketprotocol-09

Thirteenth, in the new registry created in the fifth IANA Action above,
a new registry will be created called the "WebSocket Connection Close
Code Numbers" registry. Registration rules for this registry are as follows:

1000-1999 - "Standards Action"
2000-2999 - "Specification Required"
3000-3999 - "First Come First Served"
4000-4999 - "Private Use"
All others - "Standards Action"

The registry will be populated with the following initial values:

Status Code Meaning Contact Reference
----------- ------------------------- --------------- ------------
1000 Normal Closure hybi@ietf.org [ RFC-to-be ]
1001 Going Away hybi@ietf.org [ RFC-to-be ]
1002 Protocol error hybi@ietf.org [ RFC-to-be ]
1003 Unsupported Data hybi@ietf.org [ RFC-to-be ]
1004 Frame Too Large hybi@ietf.org [ RFC-to-be ]
1005 No Status Rcvd hybi@ietf.org [ RFC-to-be ]
1006 Abnormal Closure hybi@ietf.org [ RFC-to-be ]
1007 Invalid UTF-8 hybi@ietf.org [ RFC-to-be ]

Fourteenth, in the new registry created in the fifth IANA Action above,
a new registry will be created called the "WebSocket Opcodes" registry.
The registration rules for this registry are "Standards Action" as
defined by RFC 5226.

IANA will populate the intial registry with the following values:

Opcode Meaning Reference
------- --------------------------------- -----------------
0 Continuation Frame [ RFC-to-be ]
1 Text Frame [ RFC-to-be ]
2 Binary Frame [ RFC-to-be ]
8 Connection Close Frame [ RFC-to-be ]
9 Ping Frame [ RFC-to-be ]
10 Pong Frame [ RFC-to-be ]

Fifteenth, in the new registry created in the fifth IANA Action above, a
new registry will be created called the "WebSocket Framing Header Bits"
registry. The registration rules for this registry are "Standards
Action" as defined in RFC 5226.

IANA understands that these bits are reserved for future versions or
extensions of this specification. IANA also understands that there are to be no initial registrations in this new registry.

IANA understands that these 15 actions are all that are required upon
approval of this document.

DOCUMENT SHEPHERD WRITE-UP FROM SALVATORE LORETO

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Salvatore Loreto is the document Shepherd. He has reviewed this version
(10) of the document, and believes is ready for publication.


  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has received significant review during its tenure in the
HyBi WG.

The 07 version received a TSV Directorate review by Magnus Westerlund.

The 07 version of the document underwent a WG Last Call in April 2011.

The comments received from the TSV Directorate review and WGLC have
been addressed in versions 08 and 09 of the draft.

The 09 version received a review from the responsible area director,
whose comments were substantially addressed in version 10.

The document has also received a lot of review from the HTTP community
(e.g. Mark Nottingham, Roy Fielding, Henrik Frystyk Nielsen, Julian
Reschke and others) and, most importantly, by the W3C which has already
done an official round of comments and whose concerns with respect to
the API hooks have been addressed.

The document has received a particularly intense review from the web
security community (Eric Rescorla, Adam Barth, etc.), and, as a result,
the protocol underwent a major revision in early 2011.


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

The Shepherd does not have such concerns.  As mentioned in the previous
question, the document has already received a detailed review from TSV
Directorate; moreover the security community has had very active WG
members contributing to solve the issue related to possible attacks to
HTTP proxies that do not implement correctly the HTTP Upgrade mechanism.

It is also important to mention that whereas the initial preliminary
version of websocket (the draft-hixie-thewebsokcetprotocol-76 adopted
as baseline for the WG item: -00) had been tentatively included in
browsers, and then taken out due the security concerns (briefly mentioned
above), this is being reversed indicating increasing trust in the
solution (e.g. Firefox inclusion of websocket, based on 07, in its latest
version of that software).


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The shepherd has no such concerns. The shepherd is not aware of any
IPR assertions associated with this document.


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

The document represents agreement across a broad range of participants
in the HyBi Working Group.


  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeal has been threatened, nor has extreme discontent been expressed.

However it is worth mentioning that the discussion has been extremely
contentious up to the month of December 2010/January 2011, when there was
some indication that due the lack of a valid way out some participants
might have been considering the possibility of leaving the IETF process
altogether.

The consensus around masking as a solution to the security concerns
raised at the end of 2010, although not everybody's favorite, was the
point around which the major parties agreed they could live with, and
the process began moving forward again.

Since then, the process has been more normal for an IETF WG, in that
not everyone agrees with the declared consensus points, but at least
there has been a forward movement on a regular basis.


  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts
        Checklist and http://tools.ietf.org/tools/idnits/).
        Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Here are the ID Nits per
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-10.txt

The nits are just that, nits that can be fixed in the next version (which
we will have as a result of reviews provided during IETF Last Call).

The two nits on downrefs to informational are:

RFC1951: Only *conditionally* mandatory (compression is an extension, hence, optional).
RFC2818: HTTP over TLS. Should be easy to obtain an exception for this very common reference, even if it is informational.

However those RFCs are in the downref registry:

http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

The list of nits is below.

tmp/draft-ietf-hybi-thewebsocketprotocol-10.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 13 instances of too long lines in the document, the longest
    one being 9 characters in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 2818

  ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)

  == Outdated reference: A later version (-02) exists of
    draft-ietf-websec-origin-00

    Summary: 4 errors (**), 2 warnings (==), 0 comments (--).


  (1.h) Has the document split its references into normative and
        informative?

Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

There is normative reference to draft-ietf-websec-origin, which is
expected to enter Working Group Last Call in the WEBSEC WG in the
near future.

          If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

See above.


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

Yes.

          If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?

Yes.

          Are the IANA registries clearly identified?

Yes.

          If the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?

Yes.

          Does it suggest a
        reasonable name for the new registry? See [RFC5226].

Yes.
       
          If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

None required.


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes.


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:


Technical Summary

The Abstract of the draft contains a good technical Summary, so it is copied below

Abstract

  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 if the client is a browser.  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
  clients, including browser-based applications that need two-way
  communication with servers that does not rely on opening multiple HTTP
  connections (e.g. using XMLHttpRequest or s and long polling).

Working Group Summary

  The discussion within HyBi WG was extremely contentious up to the month
  of December 2010/January 2011, when there was some indication that due
  the lack of a valid way out some participants might have been considering
  the possibility of leaving the IETF process altogether.  The consensus
  around masking as a solution to the security concerns raised at the end
  of 2010, although not everybody's favorite, was the point around which
  the major parties agreed they could live with, and the process began
  moving forward again.  Since then, the process has been more normal for
  an IETF WG, in that not everyone agrees with the declared consensus
  points, but at least there has been a forward movement on a regular basis.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?

  There are already several implementations of the protocol on different
  WebServers (e.g. Glassfish, Jetty, Apache) a library implementation (e.g.,
  libwebsocket) and from the client side Firefox has already included the
  protocol in its last version, Google has announced to include it in a
  future version of Chrome Browser and Microsoft has released an
  implementation based on 07 on its HTML5 labs site.       

        Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues?
        If there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

The 07 version received a TSV Directorate review by Magnus Westerlund.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The WebSocket protocol) to Proposed Standard


The IESG has received a request from the BiDirectional or
Server-Initiated HTTP WG (hybi) to consider the following document:
- 'The WebSocket protocol'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.  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 s and long polling).

  Please send feedback to the hybi@ietf.org mailing list.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/


No IPR declarations have been submitted directly on this I-D.