Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-05.txt

[Andy Green <[e-mail]>]

On 02/10/11 10:59, Somebody in the thread at some point said:

こんばんわ、ゆたかさん

> It would be better if the document describes expected behavior of server
> and client
> when Sec-Websocket-Protocol header is not present.

I guess it's just the degenerate case that the server only supports one 
protocol.

> o Section 2.1 - typo?
>
> What is IRI? You mean, "URL"?

It's "internationalized"

http://www.w3.org/International/O-URL-and-ident.html

> e.g.)
> 0x0: continuation frame
> 0x1: connection close (A control frame)
> 0x2: ping (A control frame)
> 0x3: pong (A control frame)
> 0x4: text frame
> 0x5: binary frame
> 0x6-F: reserved

Yes it's a nice idea.

> o Section 4.3 - Continuation frame (opcode=%x0)
>
> It is not clear to me in the document how this frame (opcode=0) is used
> while there's
> FIN bit for fragmentation/defragmentation.

Right it wasn't clear to me either.

> For example:
> [op=txt, fin=0] [op=bin, fin=0] [op=0, fin=1] <== is this for txt or bin?
>
> Is this kind of multiplexing support intended in the protocol design? If
> the doc explains
> why and how fragmentation is used.

It's not defined yet that muxing is allowed, it'll be an extension it 
seems.  When muxing is allowed, there will be a stream index in each 
fragment to allow deterministic reassembly.

> It is no clear to me what 0x43 and 0x53 are trying to achieve. In TCP,
> there is FIN with no
> details of why/who is closing for graceful shutdown.

I guess it at least is documentation if you are looking in tcpdump.

> It would be better if there is some description for why we have ping and
> pong frames,
> especially for implementers. For example, ping/pong can be used to keep TCP
> connection alive at application level which can be transparent to
> application. But it can
> also be used for app to detect 'presence' of a client for the use in the
> app.
> (# I myself can not tell what the original intention is by just reading
> -05.)

Yeah.

> As I was reading though, it took some time to find out which feature is
> for which entities
> role as in protocol layering. Ping/pong protocol for example, I am still
> not sure if
> this is done by WebSocket protocol internally or exposed to application.

In libwesockets

http://git.warmcat.com/cgi-bin/cgit/libwebsockets/

the library takes care of all control frames.  It passes a message to 
the user callback to notify PONG receipt but it just returns by default. 
  The actual CONTINUATION, CLOSE, PING, PONG service is done in the 
library without bothering user code.

BTW libwebsockets is C, LGPL2, maybe it can help you.

> Another
> examples would be the extension data filed - who is going to parse it?

For extensions that are transparent, like gzip or mux, then the 
websocket library can hide it from the user.  Anything more complicated 
will have to be a co-operation between library and user handling.

> Most of this ambiguity may be clear in the use of JS under WebSocket
> API. But I am
> coming from non-browser perspectives and I would probably need to figure
> out
> how to implement *protocol API* for non-application developers for example.

Yeah that is my situation too.

> If there's a layer structure with interfaces defined in the document,
> that would be a
> great help - something like:

I think that is probably out of scope, the protocol stands alone and 
it's best to restrict what it tries to define to what goes on the wire.

-Andy