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

Iñaki Baz Castillo <ibc@aliax.net> Sun, 24 July 2011 18:52 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 D364521F893C; Sun, 24 Jul 2011 11:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, 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 6nz7ydkFv+lo; Sun, 24 Jul 2011 11:52:34 -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 CE96B21F88A1; Sun, 24 Jul 2011 11:52:33 -0700 (PDT)
Received: by qyk9 with SMTP id 9so667763qyk.10 for <multiple recipients>; Sun, 24 Jul 2011 11:52:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.105.95 with SMTP id s31mr2761010qco.228.1311533552605; Sun, 24 Jul 2011 11:52:32 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Sun, 24 Jul 2011 11:52:32 -0700 (PDT)
In-Reply-To: <C9CD680E-8D68-4380-A76F-70F41F30F877@gbiv.com>
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> <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com> <9031.1311270000.588511@puncture> <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <B2C17B21-EA8A-4698-8C41-F55A9AA140D4@gbiv.com> <CALiegfkshhJVUHzTD1Kka5+RjGwZ5CS2J=Qk92jfSBg6Z0VfOQ@mail.gmail.com> <C9CD680E-8D68-4380-A76F-70F41F30F877@gbiv.com>
Date: Sun, 24 Jul 2011 20:52:32 +0200
Message-ID: <CALiegfkFnKjP09Vijo3c_DFYn4=UZm9M-4mVuZUyBk8rzwmDCw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: "Roy T. Fielding" <fielding@gbiv.com>
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: Sun, 24 Jul 2011 18:52:34 -0000

2011/7/24 Roy T. Fielding <fielding@gbiv.com>om>:

>>> SRV records for
>>> XMPP and MX records for mail are useful because there is only one such
>>> server expected per domain
>>
>> $ host -t srv _xmpp-server._tcp.gmail.com
>> _xmpp-server._tcp.gmail.com has SRV record 5 0 5269 xmpp-server.l.google.com.
>> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server3.l.google.com.
>> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server2.l.google.com.
>> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server4.l.google.com.
>> _xmpp-server._tcp.gmail.com has SRV record 20 0 5269 xmpp-server1.l.google.com.
>>
>> No comments.
>
> I meant server as in authority to answer for the domain, of course.

Ok. But I don't see the problem. What about Google Apps? My own domain
uses Gtalk and Gmail by setting Google XMPP SRV and MX records. Now
imagine that I would host my personal webpage (domain "www.aliax.net")
in Google, wouldn't be great a SRV entry for HTTP
(_http._tcp.aliax.net has SRV record 10 0 80
web-server-01.google.com)? or do we prefer the ugly HTTP 30X
redirection or ugly CNAME?



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

I've never thought about it when referring to SRV for WebSocket.
Honestly I just see the SRV advantages for load-balancing and
failover.


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

SRV would never be mandatory for the service provider, it's just
optional. You could still play with A entries in your test
environments (or use just A entries in production). Still don't get
the problem.





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

In my opinion SRV is not possible for HTTP since SRV appeared too
late. That's the main and enough reason IMHO.
The fact that people is "confortable" enough with HTTP style-of-life
(a specification of 1999) and does not want to deal with "new
technologies" other than stuff and more stuff on top of HTTP, is not a
good argument for me. HTTP is not the layer number 5 in OSI model.


Regards.



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