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

Norio Kobota <norio.kobota@jp.sony.com> Thu, 09 June 2011 09:28 UTC

Return-Path: <Norio.Kobota@jp.sony.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA56811E80A7 for <hybi@ietfa.amsl.com>; Thu, 9 Jun 2011 02:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydq1LH7cV630 for <hybi@ietfa.amsl.com>; Thu, 9 Jun 2011 02:28:43 -0700 (PDT)
Received: from ms6.sony.co.jp (ms6.sony.co.jp [IPv6:2001:cf8:0:56::204]) by ietfa.amsl.com (Postfix) with ESMTP id 1707611E8093 for <hybi@ietf.org>; Thu, 9 Jun 2011 02:28:41 -0700 (PDT)
Received: from mta8.sony.co.jp (mta8.sony.co.jp [IPv6:2001:cf8:0:191::15]) by ms6.sony.co.jp (R8/Sony) with ESMTP id p599SbuV019797 for <hybi@ietf.org>; Thu, 9 Jun 2011 18:28:37 +0900 (JST)
Received: from mta8.sony.co.jp (localhost [127.0.0.1]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p599SbhE014691 for <hybi@ietf.org>; Thu, 9 Jun 2011 18:28:37 +0900 (JST)
Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p599SbH6014521 for <hybi@ietf.org>; Thu, 9 Jun 2011 18:28:37 +0900 (JST)
Received: from jptkyxim101.jp.sony.com ([43.15.31.5]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 18:28:31 +0900
Received: from [43.0.235.115] ([43.0.235.115]) by jptkyxim101.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 18:28:31 +0900
Message-ID: <4DF0923D.3070005@jp.sony.com>
Date: Thu, 09 Jun 2011 18:28:29 +0900
From: Norio Kobota <norio.kobota@jp.sony.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com> <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com>
In-Reply-To: <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 09 Jun 2011 09:28:31.0413 (UTC) FILETIME=[98DF8E50:01CC2687]
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2011 09:28:44 -0000

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

(2011/06/09 17:08), Dirkjan Ochtman wrote:
> On Thu, Jun 9, 2011 at 09:38, "Andy Green (林安廸)"<andy@warmcat.com>  wrote:
>> 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
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi