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

"Roy T. Fielding" <> Sun, 24 July 2011 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 315F121F85C7; Sun, 24 Jul 2011 10:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.822
X-Spam-Status: No, score=-105.822 tagged_above=-999 required=5 tests=[AWL=-3.523, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MkFcVxv4Vmbd; Sun, 24 Jul 2011 10:56:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6192621F85B2; Sun, 24 Jul 2011 10:56:43 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 0C34D1F007C; Sun, 24 Jul 2011 10:56:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns;; b=ZRvC29jS4DOhAMQs +Hs8+p4MHqihwn8q9Nwp2rLNHLV2nQhZtvikCjcpRFK+Ynl6p4a7h2WWIWfzO9e6 +OFAJgn+tLM+s15xCdKRn7YM75W1FsSZUwVgU7X/QJeE3NOuPvHci7YW1hNrVG1v bfqx+WwdXB60ayt1SgrYDIsGqbg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=tFMP/mBbwmvsZgtn7F6q7h+RYN8=; b=QOUExY6ESAVWqtk78QcnSBmbkW+p 70RuF3+7+GjlmZ59IRNbkbBHYFZ7FRAgefyLrZOkjEeq/VirfZP/l32Oa6SW17L+ 2I8GZFUibOboxJ6TakRVKLETg1y1x6zu5nlsor8ZFbpfkV0qy+uNe9SvNJFtGeU/ WlFjF9AO9MbyOIU=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id AFBB51F0078; Sun, 24 Jul 2011 10:56:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Sun, 24 Jul 2011 10:56:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <9031.1311270000.588511@puncture> <> <> <>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <>
X-Mailer: Apple Mail (2.1084)
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: Sun, 24 Jul 2011 17:56:44 -0000

On Jul 24, 2011, at 4:42 AM, Iñaki Baz Castillo wrote:

> 2011/7/23 Roy T. Fielding <>om>:
>>> Right. If WS borns with no SRV (as a MUST for WS clients) then just
>>> forget it and let inherit all the ugly limitations from HTTP protocol.
>> I am tired of this.  SRV is not used for HTTP because SRV adds latency
>> to the initial request for no useful purpose whatsoever.
> And I'm really tired of hearing the argument of the "latency" which
> nobody demostrates (but just talks about it without replying me how
> the same is not a problem in realtime protocols like SIP and XMPP).

Try using a protocol analyzer.  It is a problem with SIP and XMPP.
Chat and telephony have different user expectations about the initial
connect time, so people just don't notice it as much as they do when
a web page rendering process stalls because embedded resources require
two additional DNS requests.

>> SRV records for
>> XMPP and MX records for mail are useful because there is only one such
>> server expected per domain
> $ host -t srv
> has SRV record 5 0 5269
> has SRV record 20 0 5269
> has SRV record 20 0 5269
> has SRV record 20 0 5269
> has SRV record 20 0 5269
> No comments.

I meant server as in authority to answer for the domain, of course.

>> and it is *very* desirable to maintain central
>> control over that routing.
> I don't know what this means.

It means that admins care a great deal about what machines in the network
are allowed to receive mail for that network, and likewise for XMPP, since
both are store and forward protocols that contain messages with personal
information for individual addresses which are routed on a hop-by-hop basis.
HTTP has none of those characteristics.  Hence, Mail and XMPP are centralized
services for an entire domain, whereas HTTP services are specific to the
services provided by each individual host.

>>  In contrast, HTTP is deployed in an anarchic
>> manner in which there are often several HTTP servers per machine
>> (e.g., tests, staging, production, CUPS, etc,).
> Could you explain me why DNS A is good but DNS SRV is bad in such
> "anarchic" deployments?

Because DNS A for a server is deployed as soon as the server is made
available on the network (Intra or Inter).  It is one of the first things
done when installing an OS.  SRV, in contrast, requires that the zone
manager reconfigure DNS.

>>  AFAICT, WebSockets is
>> even more anarchic than HTTP -- it will have to be, given that the sane
>> network admins will block it by default.
> ------------------------
>   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).
> ------------------------


>> In short, SRV is not used by the Web because it is inappropriate for HTTP.
>> I have seen no reason to believe that it would be appropriate for WebSockets.
>> If you want SRV to be part of the proposed standard, then you have to convince
>> the people implementing WS to use SRV.  None have done so, yet, so we can't
>> expect the editor to add it to the spec just because you have an opinion.
> Ok, so the argument "I don't know SRV but I feel fine with HTTP
> limitations for years" will win. Great design decissions.

No, the argument is that I know SRV, I know a lot more about HTTP, and I know
for a fact that SRV is not desirable for HTTP.  So, whenever you suggest that
lack of SRV is somehow a failing of HTTP, you should understand that it makes
your arguments look clueless.  Please, find some other example.