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

David Endicott <dendicott@gmail.com> Thu, 21 July 2011 16:07 UTC

Return-Path: <dendicott@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 155B321F89B8; Thu, 21 Jul 2011 09:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level:
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 3QllEeBxwjex; Thu, 21 Jul 2011 09:07:01 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC8F321F898F; Thu, 21 Jul 2011 09:07:00 -0700 (PDT)
Received: by wwe5 with SMTP id 5so949103wwe.13 for <multiple recipients>; Thu, 21 Jul 2011 09:06:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h8z57ttMAhThF8Rtr5IrPUmU/xRh9YunRRIrd61xPEg=; b=jfwb993X5RivII7UnG++fY7iad1GnMqHX5iqknJKS/nkzWRtq7W8aWBfKFZSdOScA0 cZsR2mrCEBpawpyP8WomOD12Zv5F64YebxcukO6xb9PGxT/qTPdlAg9uZYNY/ybc/GYO dl4SR5RY1IUUb9Kgv4mFc+ewiYz6FuvWDVlm8=
MIME-Version: 1.0
Received: by 10.216.63.21 with SMTP id z21mr1029991wec.3.1311264419703; Thu, 21 Jul 2011 09:06:59 -0700 (PDT)
Received: by 10.216.39.197 with HTTP; Thu, 21 Jul 2011 09:06:59 -0700 (PDT)
In-Reply-To: <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <CALiegfk0zVVRBbOP4ugsVXKmcLnryujP6DZqF6Bu_dC2C3PpeQ@mail.gmail.com> <9031.1311082001.631622@puncture> <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com>
Date: Thu, 21 Jul 2011 12:06:59 -0400
Message-ID: <CAP992=Ft6NwG+rbcuWUP0npwVNHY_znHmXmznBQO_krMo3RT6g@mail.gmail.com>
From: David Endicott <dendicott@gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Content-Type: multipart/alternative; boundary="000e0cd3b54ef16b5c04a8968927"
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 16:07:02 -0000

I am opposed to inclusion in core specification.  I would accept it as
optional extension.

DNS resolution is not a function of a transport protocol.  DNS SRV has no
special association with WS.    It is my opinion that this would be
additional cruft that is only marginally related to the purpose and function
of websockets.    It does not address a general use case.   DNS SRV applies
only to a (small?) subset of server-side implementations.    It is a good
and useful mechanism, but I do not believe it should be tied tightly to
websockets, nor included as part of the core spec.


On Wed, Jul 20, 2011 at 5:12 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2011/7/19 Dave Cridland <dave@cridland.net>:
> >> 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.
>
>
> Unfortunaltely it seems that the debate about DNS SRV support does not
> interest to the core WG authors. I would like, at least, to receive
> good arguments not to include/mandate DNS SRV support in the draft. If
> not, the proposal is just being ignored with no reason.
>
> Regards.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>