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

Bruce Atherton <> Thu, 21 July 2011 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38CE811E8079; Thu, 21 Jul 2011 16:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KjddOSxWibxp; Thu, 21 Jul 2011 16:47:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B08FF11E8075; Thu, 21 Jul 2011 16:47:29 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpa (Exim 4.69) (envelope-from <>) id 1Qk2xk-0000G8-IB; Thu, 21 Jul 2011 16:47:28 -0700
Message-ID: <>
Date: Thu, 21 Jul 2011 16:47:41 -0700
From: Bruce Atherton <>
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Dave Cridland <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <9031.1311270000.588511@puncture> <> <> <> <9031.1311286867.939466@puncture>
In-Reply-To: <9031.1311286867.939466@puncture>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
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:47:30 -0000

On 21/07/2011 3:21 PM, Dave Cridland wrote:
> SRV lookup is pretty commonplace now in libraries. XMPP and SIP 
> clients have no difficulty finding this functionality in a wide 
> variety of environments. For the web, where there are substantially 
> fewer web browsers than there are XMPP clients, I don't think this 
> would pose any kind of problem.

Oh, it isn't hard, but it violates the principle of least surprise. Most 
people think they know how to code name resolution by using 
gethostbyname() or equivalent. And to do it efficiently, especially when 
we are operating in a world that is predominantly driven by HTTP 
servers, requires complexities like dealing with asynchronous calls to 
fetch the A and SRV records at the same time under the assumption that 
the SRV record probably won't exist.

>> It can be argued that not using a MUST may well open up 
>> interoperability problems because some Websockets clients contact the 
>> wrong host. However, keep in mind that in the older SIP RFC2543 it 
>> provided two resolution mechanisms. It specified that clients SHOULD 
>> look up address records, but MAY use the DNS SRV mechanism. SIP 
>> survived that without too much of a hassle. And specifying that 
>> Websockets clients SHOULD use DNS SRV, but MAY use address records 
>> alone looks like an improvement.
> SIP survived because it was very small. I don't see WS making a 
> transition, in the same way that repeated attempts have failed to move 
> HTTP to SRV.
> Dave.

As I understand it, the issue that caused the various drafts for HTTP 
SRV to die without getting much traction is one of efficiency. It is 
inefficient to make all these extra DNS calls, especially when it is 
unlikely that many of the records you are blocking on will exist. Other 
than the inefficiency, HTTP SRV is just an incremental technology you 
add to your existing DNS without hurting what already exists. Since 
Websockets uses the same infrastructure the records are unlikely to 
exist for it either, so the inefficiency issues are still present.

Hmm, I seem to be arguing myself out of supporting DNS SRV as the 
preferred location mechanism. That is not the case. I just think that we 
face some of the same challenges migrating Websockets to SRV as are 
faced by HTTP because we share the same environment for the most part. 
Willy's example of a proxy that doesn't know how to resolve host names 
using the SRV method is a good example. But by advocating for the 
deployment of SRV records as a best practice for Websockets, we may 
improve things in the HTTP world as well. It is a shame there is no 
standard defined for HTTP SRV to point to.