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

David Endicott <> Thu, 21 July 2011 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F337521F8770; Thu, 21 Jul 2011 10:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.586
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TB+hTqshj2hr; Thu, 21 Jul 2011 10:18:33 -0700 (PDT)
Received: from ( []) by (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;; 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 with SMTP id z21mr1098023wec.3.1311268711646; Thu, 21 Jul 2011 10:18:31 -0700 (PDT)
Received: by with HTTP; Thu, 21 Jul 2011 10:18:31 -0700 (PDT)
In-Reply-To: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <>
Date: Thu, 21 Jul 2011 13:18:31 -0400
Message-ID: <>
From: David Endicott <>
To: Willy Tarreau <>
Content-Type: multipart/alternative; boundary=000e0cd3b54ec3487a04a897891d
Cc: Server-Initiated HTTP <>, IETF-Discussion <>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:

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