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

Willy Tarreau <w@1wt.eu> Thu, 21 July 2011 16:39 UTC

Return-Path: <w@1wt.eu>
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 C094F21F8A55; Thu, 21 Jul 2011 09:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.534
X-Spam-Level:
X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=-3.791, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
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 nuqn+XXjkC52; Thu, 21 Jul 2011 09:39:21 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8521F8A30; Thu, 21 Jul 2011 09:39:20 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6LGdAtf016954; Thu, 21 Jul 2011 18:39:10 +0200
Date: Thu, 21 Jul 2011 18:39:10 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
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:39:21 -0000

On Thu, Jul 21, 2011 at 06:27:49PM +0200, Iñaki Baz Castillo wrote:
> 2011/7/21 David Endicott <dendicott@gmail.com>om>:
> > 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