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 17:18 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 F337521F8770; Thu, 21 Jul 2011 10:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.586
X-Spam-Level:
X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TB+hTqshj2hr; Thu, 21 Jul 2011 10:18:33 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97E7221F876A; Thu, 21 Jul 2011 10:18:32 -0700 (PDT)
Received: by wyj26 with SMTP id 26so1146003wyj.31 for <multiple recipients>; Thu, 21 Jul 2011 10:18:31 -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=JnYrzouHZYlzhVl0Vgf3xfIZaBJjTwbFMjRYY7s4Ots=; b=ZfSqk3IhD2j0wqbkOu5P2VTBh9IUcI4nvxT4T98c69Z1TraGouJZri3XQtPBRf7r93 jncBqB3JgmnJkXjJ6LGyrtmDAZapfPYcnCTJduE9yDar/YeTbNtF5hOemFkoZXpXkCwl qlUF+5hxUsXrcIysZJvUFM9olRAK3HLKjqSJA=
MIME-Version: 1.0
Received: by 10.216.63.21 with SMTP id z21mr1098023wec.3.1311268711646; Thu, 21 Jul 2011 10:18:31 -0700 (PDT)
Received: by 10.216.39.197 with HTTP; Thu, 21 Jul 2011 10:18:31 -0700 (PDT)
In-Reply-To: <20110721163910.GA16854@1wt.eu>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <CALiegfk0zVVRBbOP4ugsVXKmcLnryujP6DZqF6Bu_dC2C3PpeQ@mail.gmail.com> <9031.1311082001.631622@puncture> <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com> <CAP992=Ft6NwG+rbcuWUP0npwVNHY_znHmXmznBQO_krMo3RT6g@mail.gmail.com> <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com> <20110721163910.GA16854@1wt.eu>
Date: Thu, 21 Jul 2011 13:18:31 -0400
Message-ID: <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com>
From: David Endicott <dendicott@gmail.com>
To: Willy Tarreau <w@1wt.eu>
Content-Type: multipart/alternative; boundary="000e0cd3b54ec3487a04a897891d"
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 17:18:34 -0000

Thanks Willy, you made my point better than I did.

It is my opinion that name resolution (however done) is outside the purview
of WS.   It may be handled in any number of ways by the client, and must
happen *before* WS establishes it's TCP connection and begins handshaking.

DNS, DNS SRV, etc. are good and useful tools, but are not part of WS.

A document showing how to use DNS SRV with WS would be useful, but it's not
part of the core WS spec.


On Thu, Jul 21, 2011 at 12:39 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Jul 21, 2011 at 06:27:49PM +0200, Iñaki Baz Castillo wrote:
> > 2011/7/21 David Endicott <dendicott@gmail.com>:
> > > 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.
> >
> > An WebSocket URI is given to a WebSocket client, and the client MUST
> > locate the corresponding WS server, right? and for locating the server
> > the client MUST follows a procedures which, for now, involve (if it's
> > not an IP) DNS A/AAAA resolution, right? So now imagine that the
> > location mechanism is a bit more powerful and also involves SRV
> > queries (not always).
> >
> > If you think that a transport protocol (like WebSocket) must not
> > resolve a server destination then also remove the WS URI inspection
> > and resolution from the core spec, don't you agree? or just DNS A/AAA
> > is valid?
> >
> > I don't agree with your opinion at all. Regards.
>
> Iñaki,
>
> I understand the point David is making. DNS is something independant of
> WS and conversely. It is one way of resolving addresses, just like there
> will be people using hosts files. At no place the protocol specification
> dictates how a client should resolve a name to an IP address. The protocol
> specifies the transport part only.
>
> This is the same for other protocols. For instance, neither FTP nor HTTP
> explain how a client is supposed to resolve a host name, still the later
> explains how to parse a URI. DNS SRV is a DNS extension which only concerns
> resolvers. Not all clients will be using resolvers, just a part of them.
> Some others will simply forward the request to their HTTP proxy which will
> apply whatever DNS resolving method they know, including possibly DNS SRV.
>
> In practice, if there are new elements of DNS SRV that are specific to WS,
> they should probably be added to the DNS SRV spec and not the WS spec.
> Maybe the WS spec should mention that it addresses transport only and
> not address resolving. It may recommend to follow some principles to
> perform the resolving but should not specify how to do it.
>
> Hoping it's a bit clearer,
> Willy
>
>