Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Mykyta Yevstifeyev <evnikita2@gmail.com> Thu, 21 July 2011 03:28 UTC

Return-Path: <evnikita2@gmail.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 03BDA21F8757; Wed, 20 Jul 2011 20:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.509
X-Spam-Level:
X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 aaYNbR+77Vn5; Wed, 20 Jul 2011 20:28:00 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0932621F874F; Wed, 20 Jul 2011 20:27:59 -0700 (PDT)
Received: by fxe4 with SMTP id 4so3291209fxe.27 for <multiple recipients>; Wed, 20 Jul 2011 20:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Z5XAGNmz/bWaDK7/NBDl2Q89eIxOOWp//bBzEErppww=; b=gkgRQS/zAQ4njAq+wCTEe2GCEYKiZytddSfe6mUHSd3L6Bohy+GJslh1Q43sTiJRWk O+FVvdjNX7l0h6F1SlqxOIHkd0bza2YT/iylIzlsCQS4EqV+jHeh5QYjlVjAV8fe/rD6 YsqJ7GyaHvZqM/PZtGe6uLJgkP5z7qdswZd2Q=
Received: by 10.223.77.92 with SMTP id f28mr4289492fak.37.1311218879150; Wed, 20 Jul 2011 20:27:59 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w11sm1107664faj.14.2011.07.20.20.27.56 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 20:27:58 -0700 (PDT)
Message-ID: <4E279CE9.8090800@gmail.com>
Date: Thu, 21 Jul 2011 06:28:41 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <CALiegfk0zVVRBbOP4ugsVXKmcLnryujP6DZqF6Bu_dC2C3PpeQ@mail.gmail.com> <9031.1311082001.631622@puncture>
In-Reply-To: <9031.1311082001.631622@puncture>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Thu, 21 Jul 2011 08:27:41 -0700
Cc: Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
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, 21 Jul 2011 03:28:01 -0000

I support the opinion that SRV mechanism for use with WebSocket should 
be incorporated in the core WS specification.  Mykyta

19.07.2011 16:26, Dave Cridland wrote:
> On Tue Jul 19 12:51:16 2011, Iñaki Baz Castillo wrote:
>> 2011/7/11 The IESG <iesg-secretary@ietf.org>rg>:
>> > The IESG has received a request from the BiDirectional or
>> > Server-Initiated HTTP WG (hybi) to consider the following document:
>> > - 'The WebSocket protocol'
>> > <draft-ietf-hybi-thewebsocketprotocol-10.txt> as a Proposed Standard
>>
>> Hi, I assume there is no interest in making DNS SRV mechanism exposed
>> in http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02 part of
>> the WebSocket core specification, neither referencing it (in the same
>> way RFC 3261 "SIP protocol" mandates the usage of RFC 3263 "Locating
>> SIP servers").
>>
>> As said before, making such DNS SRV specification an extension (so
>> present in other document) will mean no success at all, as WebSocket
>> client implementors (i.e. webbrowser vendors) will not be mandated to
>> implement it and service providers could not rely on the support of
>> DNS SRV in web browsers. So nobody will use them (because IE10 decided
>> not to implement it, for example). IMHO this is sad due the real
>> advantages DNS SRV provides for a protocol like WebSocket.
>>
>> Yes, in HTTP there is no special DNS stuff, all the load-balancing and
>> failover mechanism are done at server side with very complex and
>> expensive solutions (www.facebook.com resolves to a single IPv4 !!!!).
>> The question is: should we also inherit every HTTP limitation in
>> WebSocket?
>
> I agree wholeheartedly with this, and strongly recommend that 
> mandatory use of SRV is included in the core protocol.
>
> I think with HTTP's very short lived requests, then it's possible to 
> work around the lack of SRV support (at a cost), but the benefit is 
> markedly higher with the long-lived, stateful sessions we're 
> anticipating with WebSocket.
>
> Dave.