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

Iñaki Baz Castillo <> Thu, 21 July 2011 23:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF30A21F869E; Thu, 21 Jul 2011 16:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Status: No, score=-2.67 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GtwtQLsgDXk8; Thu, 21 Jul 2011 16:19:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 990BD21F8680; Thu, 21 Jul 2011 16:19:42 -0700 (PDT)
Received: by qyk9 with SMTP id 9so4596219qyk.10 for <multiple recipients>; Thu, 21 Jul 2011 16:19:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id l25mr725161qci.265.1311290381925; Thu, 21 Jul 2011 16:19:41 -0700 (PDT)
Received: by with HTTP; Thu, 21 Jul 2011 16:19:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <9031.1311270000.588511@puncture> <> <> <> <> <9031.1311279546.247694@puncture> <>
Date: Fri, 22 Jul 2011 01:19:41 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: David Endicott <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 23:19:43 -0000

2011/7/21 David Endicott <>om>:
> Yes, those are all excellent reasons to use DNS SRV.   None of them are a
> reason to mandate that WS require it.   Because something is good for some
> (or many) use cases, does not mean it is appropriate for everything and
> certainly is not a reason to mandate it as a requirement.

Hi David, I will be away for some days until I can read all the new
mails in this thread (I'll do it and will reply in a few days).
In the meanwhile I strongly ask you to read the draft about DNS SRV in

Sepecially some sections:

   1. Introducion


   DNS SRV mechanism facilitates network applications scalability
   without requiring an intermediary node distributing the traffic in
   load-balancing or failover fashion.  Instead, DNS SRV mechanism just
   requires a proper DNS setup.

   By introducing DNS SRV records into WebSocket protocol
   [I-D.ietf-hybi-thewebsocketprotocol], WebSocket providers can,
   optionally, take same advantages and provide scalable services with a
   minimal infrastructure.

   This specification mandates the usage of DNS SRV resource records by
   WebSocket clients when resolving a "ws:" or "wss:" URI [RFC3986], but
   still leaves the decision of using SRV records up to the service

  3. Implementation


   It is up to the system administrator whether to set, or not, DNS SRV
   resource records for the WebSocket protocol within the provided
   service.  This specification allows the system administrator to use
   the DNS SRV [RFC2782] mechanism to improve the service reliability by
   providing load-balancing and failover capabilities, but does not
   mandate it (the system administrator could choose whichever
   scalability strategy).

Section 4 "Client Usage" in which is shown how the WS client should
perform SRV resolution just in case the WS URI is a domain and no port
is present in the URI:

   To clarify it, a WebSocket URI like "ws://"
   requires the client to perform SRV resolution while
   "ws://" does not (as the port is explicitly
   present in the URI).

   step 3:  If there is no SRV result, attempt the fallback process described
       in Section 4.2 and omit next steps.

   4.2.  Fallback Process

   The fallback process SHOULD be a normal A or AAAA address record
   resolution to determine the IPv4 or IPv6 address of the URI host
   component (or URI host value without DNS resolution if it contains an
   IP address).

   The server connection port is obtained as stated in Section 3.1 of

NOTE: The section 3.1 has changed in the new WS draft. It pointed to
(3.1.  Parsing WebSocket URIs)

Also, the section 5 (Examples) should clarify it even more.


Iñaki Baz Castillo