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

Mark Andrews <marka@isc.org> Mon, 25 July 2011 03:21 UTC

Return-Path: <marka@isc.org>
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 D540411E8074; Sun, 24 Jul 2011 20:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level:
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599]
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 KsKN26D-3V1M; Sun, 24 Jul 2011 20:21:56 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id F0AFF11E8072; Sun, 24 Jul 2011 20:21:55 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0AC5E5F98EF; Mon, 25 Jul 2011 03:21:41 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E7C52216C84; Mon, 25 Jul 2011 03:21:38 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A36701222CE2; Mon, 25 Jul 2011 13:21:36 +1000 (EST)
To: Keith Moore <moore@network-heretics.com>
From: Mark Andrews <marka@isc.org>
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> <20110724073323.EEAAF121E985@drugs.dv.isc.org> <4B3C19FD-B736-4DA7-9DB5-3D433320DCBC@network-heretics.com>
In-reply-to: Your message of "Sun, 24 Jul 2011 22:47:39 -0400." <4B3C19FD-B736-4DA7-9DB5-3D433320DCBC@network-heretics.com>
Date: Mon, 25 Jul 2011 13:21:36 +1000
Message-Id: <20110725032136.A36701222CE2@drugs.dv.isc.org>
X-Mailman-Approved-At: Sun, 24 Jul 2011 22:10:19 -0700
Cc: "Roy T. Fielding" <fielding@gbiv.com>, 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: Mon, 25 Jul 2011 03:21:57 -0000

In message <4B3C19FD-B736-4DA7-9DB5-3D433320DCBC@network-heretics.com>om>, Keith M
oore writes:
> On Jul 24, 2011, at 3:33 AM, Mark Andrews wrote:
> 
> > How do you solve the problem of hosting just "http://example.com/"
> > on "s1.joes-web-service.com" and not redirect everything else at
> > example.com?  People have been complaining about this for about as
> > long as the web has existed.
> 
> Well, in a way, that's what NAPTR was for.  All of the UR
> i resolution mechanisms (equally applicable to DNS-based URIs) that were =
> developed and never really used grew out of the original realization in =
> the early 1990s that CERN could stop hosting the original web pages if =
> it wanted to, and there was no way to keep those links from going stale.

NAPTR is not defined for HTTP.
SRV is not defined for HTTP.
 
> The problem never went away, but the DNS-based solutions were defined a =
> long time ago and never used.

No.  It was explitly NOT defined.

RFC 2782
Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.

> By now, I think the market has long =
> since decided.  For better or worse, the mechanism the market chose to =
> use with the web was HTTP redirects.

If the market hasn't has a really opportunity do decide as only one
mechanism has been specified and coded.  Most people don't know of
the existence of SRV or that it would be useful for HTTP.

If the only tool you have is a hammer then you use a hammer even
if a screwdriver would be better.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org