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 11:11 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 34FF021F8B25; Sun, 24 Jul 2011 04:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level:
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.007, 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 awN6d44iFjwB; Sun, 24 Jul 2011 04:11:04 -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 8768821F8B11; Sun, 24 Jul 2011 04:11:04 -0700 (PDT)
Received: by qyk9 with SMTP id 9so547470qyk.10 for <multiple recipients>; Sun, 24 Jul 2011 04:11:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.105.95 with SMTP id s31mr2537878qco.228.1311505862938; Sun, 24 Jul 2011 04:11:02 -0700 (PDT)
Received: by 10.229.185.195 with HTTP; Sun, 24 Jul 2011 04:11:02 -0700 (PDT)
In-Reply-To: <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.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> <CAP992=FJymFPKcPVWrF-LkcEtNUz=Kt9L_ex+kLtjiGjL1T46w@mail.gmail.com> <4E28A51F.4020704@callenish.com> <9031.1311286867.939466@puncture> <4E28BA9D.6010501@callenish.com> <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.com>
Date: Sun, 24 Jul 2011 13:11:02 +0200
Message-ID: <CALiegfnwNyYDy=SyrqHJXV0ZreADb7F8QySvgdHofW9Hm9miZQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: David Endicott <dendicott@gmail.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 11:11:06 -0000

2011/7/22 David Endicott <dendicott@gmail.com>:
> The technological advantages are worthy, when it's used, but when it doesn't
> come into play, there are added inefficiencies.

~100 ms (if the DNS server is not local and there is no DNS cache for
the given domain). And just during the WS connection, no more. Taking
into account that a WS will be *usually* connected after loading a web
page, such ~100ms in a non-full-realtime protocol is insignificant.


> Also the name resolution
> of the HTTP that serves the Javascript that opens the WS should remain
> constant.

Why?


> If WS resolves the host/domain to a different address than the
> HTTP it was spawned from, it becomes a method to bypass same-origin / CORS
> restrictions.

No, you are wrong. You are doing invalid assumptions (in all the
thread) about how SRV works. Perhaps you should learn about it before
making such assertions. Maybe if you read
http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02#section-4.1:


   When the client constructs the WebSocket handshake HTTP request, the
   URI MUST be set as described in Section 3.2 of
   [I-D.ietf-hybi-thewebsocketprotocol] regardless of the usage of SRV
   mechanism.  This is, DNS SRV resolution for a "ws:" or "wss:" URI
   does not alter the usual construction of the WebSocket handshake
   request.



> I favor a minimalist core with extensibility.    Name resolution happens
> before the WS opening handshake, so I continue to see this as outside the
> domain of the WS protocol.   I would prefer that name resolution be provided
> by a selectable method.  That way, in 20 years, when name resolution needs
> have again changed, we'll have the ability to adapt.

This does not make sense, even if you have been saying the same during
all the thread. So, do you think that a mail client can *select* how
to resolve mailto:alice@gmail.com? why??? obviously if the mail client
does not perform DNS MX resolution for gmail.com things will not work,
why? because mail servers destinations are specified via DNS MX
resource records and because the SMTP protocol mandates it.


David, don't take me wrong but:

- You are speaking about SRV with no knowlodegde enough about it (so
making really wrong assumptions).
- You have a vision about "resolving URI's" that does not fit well in
the real world. The protocol/specification decides how resolution
takes place, rather than the client.


Regards.


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