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

[Takeshi Yoshino <[e-mail]>]

Hi Yutaka-san,

On Thu, Feb 10, 2011 at 19:59, <[e-mail]> wrote:

>
> o Section 1.3 - discrepancy in SHA1 hash value:
>
> My python says:
> >>> h = hashlib.sha1()
> >>> h.update('dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
> C5AB0DC85B11')
> >>> h.hexdigest()
> '1b334d8e1b8d57c1c7a214517c106abc434282b8'
>
>
remove a space between 95CA- and C5AB, and you get what's on the spec.

>>> import hashlib
>>> h = hashlib.sha1()
>>> h.update('dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11')
>>> h.hexdigest()
'b37a4f2cc0624f1690f64606cf385945b2bec4ea'


> o Section 4.5.1 - the term "body"
>
> For consistency, it should be replaced with Application Data, or "body" be
> defined explicitly in the document.
>
>
agreed

>
> o Section 4.5.1 - Close handshake
>
> 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.
>
>
Actually, it's not intended to indicate who's closing, but to make sure what
the close frame really means, i.e. it's close initiation or close
acknowledgement. Using an analogy of TCP, close S from server is FIN, and
close S from client is ACK for server's FIN.

Without this, each peer cannot know
- the other peer just initiated close
or
- the other peer received close frame and acknowledged it

Imagine both peers send out close initiation at approximately same time.
They looks like acknowledgement but are not.

Once we can perfectly distinguish initiation and acknowledgement as
described above, we can assume "If A received close acknowledgement from B,
B has received all the data sent from A before close successfully".

If you have any idea about the usefulness of this closing handshake design,
please come to the thread "Clarify the role of closing handshake" and speak
out. We're discussing it now.

Takeshi