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 17:33 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 1393E21F85AE; Thu, 21 Jul 2011 10:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.444
X-Spam-Level:
X-Spam-Status: No, score=-5.444 tagged_above=-999 required=5 tests=[AWL=-3.701, 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 hxrvjb4r1+uC; Thu, 21 Jul 2011 10:33:45 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7018A21F85A3; Thu, 21 Jul 2011 10:33:44 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6LHXcjT017171; Thu, 21 Jul 2011 19:33:38 +0200
Date: Thu, 21 Jul 2011 19:33:38 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110721173338.GB16854@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> <CALiegfkk8G6_KE-KfL_RuF96NUbF6yZgcFfsNGtLoAr2=jcYjg@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: <CALiegfkk8G6_KE-KfL_RuF96NUbF6yZgcFfsNGtLoAr2=jcYjg@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 17:33:46 -0000

On Thu, Jul 21, 2011 at 07:15:13PM +0200, Iñaki Baz Castillo wrote:
> 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).

But you can't make usage of DNS a MUST. While it generally is acceptable
over the wide Internet, it's almost always anti-pattern on internal
networks. Application developers in particular can never rely on this
because the guy who manages the DNS is not the same who manages servers
and generally doesn't accept to add any input for an application that is
not in production. Similarly, DNS which announce "public" records for
some services will cause trouble to local clients which would always
make use of the DNS first because of the MUST, and would not be able
to connect to the local address:port which is not announced anywhere.

If someone were to develop a backup/restore solution based on WS, it would
be funny to discover that it cannot be used to restore the DNS server when
this one fails...

However in my opinion it could be good to document a recommended DNS
architecture for WS, that is judged optimal and the most interoperable.
This could clearly be a separate RFC suggesting how clients and server
can make use of DNS SRV records for HA and LB.

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

Then maybe the name should be reserved as soon as the protocol spec is
released, and the document should refer to it.

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

MAY

> But that is not true now as WS
> core spec states simple A/AAAA resolution for locating a WS server.

It does not even say that. It only talks about DNS when suggesting how
a client may select a limit on the number of concurrent connections (#5.1).

Regards,
Willy