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

Iñaki Baz Castillo <ibc@aliax.net> Thu, 21 July 2011 17:15 UTC

Return-Path: <ibc@aliax.net>
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 B6A3921F874C; Thu, 21 Jul 2011 10:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level:
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NykDk76jRSDV; Thu, 21 Jul 2011 10:15:15 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 048D821F84E0; Thu, 21 Jul 2011 10:15:14 -0700 (PDT)
Received: by qyk9 with SMTP id 9so4401456qyk.10 for <multiple recipients>; Thu, 21 Jul 2011 10:15:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.66.25 with SMTP id l25mr440360qci.265.1311268514022; Thu, 21 Jul 2011 10:15:14 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Thu, 21 Jul 2011 10:15:13 -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 19:15:13 +0200
Message-ID: <CALiegfkk8G6_KE-KfL_RuF96NUbF6yZgcFfsNGtLoAr2=jcYjg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Willy Tarreau <w@1wt.eu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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:15:15 -0000

2011/7/21 Willy Tarreau <w@1wt.eu>eu>:
> 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.

Host files just replace A/AAAA resolution. Still is possible to query
SRV records and later perform hostfiles check for retrieved hostnames
(instead of performing DNS A/AAAA for them).


> 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.

Maybe because DNS SRV born later than FTP or HTTP. But now look at SIP
and XMPP protocols which make *extensive* usage of DNS SRV. And SIP is
just a "signaling protocol", you could also consider it a "transport
protocol" which transports sessions and other kind of data. It's at
the very same level than WS, IMHO.



> 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.

If WS spec does not mandate DNS SRV resolution in WS clients (so
webbrowsers mainly) then let's forget SRV balancing/failover
capabilities. If the WS core draft does not want to handle this topic,
then refer to another document mandating it (in the same way SIP RFC
3261 mandates the usage of DNS NAPTR/SRV in RFC 3263 for SIP clients).

So you can split WS in:
- transport specification RFC (handshake, frames and so).
- location WS servers (a MUST for WS clients when resolving WS URI's).


> 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.

No. DNS SRV spec (RFC 2782) just explains the DNS SRV mechanism. Any
protocol can decide wheter to include/mandate it or not. Each protocol
can register in IANA new "service" values SRV, in the same way SIP and
XMPP RFC's create "sip" and "xmpp-server" values.


> 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.

That would be great, so another document/spec would *mandate* how WS
clients MUST resolve WS destinations. But that is not true now as WS
core spec states simple A/AAAA resolution for locating a WS server.


Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>