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

Dave Cridland <dave@cridland.net> Thu, 21 July 2011 20:19 UTC

Return-Path: <dave@cridland.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 362E121F8A55; Thu, 21 Jul 2011 13:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level:
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 u6-w6mgFjOiP; Thu, 21 Jul 2011 13:19:15 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id F062021F8915; Thu, 21 Jul 2011 13:19:14 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 83CF01168087; Thu, 21 Jul 2011 21:19:09 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrXk6cjRLl1Z; Thu, 21 Jul 2011 21:19:06 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 435071168067; Thu, 21 Jul 2011 21:19:06 +0100 (BST)
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> <CALiegfnGkypkJYxUGGm3Tddgk3D0Ri=EWtN0WMChhEZN3Xsauw@mail.gmail.com> <CAP992=FrnDrCLgqZGUO9R2WkfgA2D+8TCau=6Xi+xa_u3CXT2w@mail.gmail.com>
In-Reply-To: <CAP992=FrnDrCLgqZGUO9R2WkfgA2D+8TCau=6Xi+xa_u3CXT2w@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <9031.1311279546.247694@puncture>
Date: Thu, 21 Jul 2011 21:19:06 +0100
From: Dave Cridland <dave@cridland.net>
To: David Endicott <dendicott@gmail.com>, Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>, Willy Tarreau <w@1wt.eu>, Iñaki Baz Castillo <ibc@aliax.net>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
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: Thu, 21 Jul 2011 20:19:16 -0000

On Thu Jul 21 19:43:07 2011, David Endicott wrote:
> I do not know SIP or XMPP well enough to comment on why they  
> mandated the
> name resolution mechanisms they did.    However, XMPP is used in a  
> highly
> dynamic host environment, so having flexible & extensible name  
> resolution is
> likely an excellent choice.
> 
> 
I have no idea what you might mean by "highly dynamic host  
environment" in this context, but XMPP servers are normally found at  
the same location consistently. However, it is *not* always (or  
typically) the same location as a simple A record lookup:

;; ANSWER SECTION:
_xmpp-server._tcp.isode.com. 259200 IN	SRV	5 0 5269 xmpp.isode.com.

;; ADDITIONAL SECTION:
xmpp.isode.com.		225364	IN	A	62.3.217.250

;; ANSWER SECTION:
isode.com.		73130	IN	A	87.106.143.99

This property alone is very useful - in a websockets case this would  
mean being able to provide websockets services from a different host  
(or network) to the traditional web services in a simple manner,  
fully compatible with SOP.

The fact that this also allows cheap lightweight load balancing and  
fallback control is also useful in other cases; none of this relates  
to dynamic hosts, but simply richer service location.


> I do not oppose DNS's MX records for SMTP as email addresses are  
> name@domain,
> so obviously the Domain Name System is appropriate.    Also, I fail  
> to see
> why a mail admin should care how the SMTP clients arrive at the  
> server.  DNS
> MX is a reasonable solution, but there may be other methods, any  
> and all of
> which are irrelevant to the SMTP server.    Especially when the  
> SMTP server
> supports multiple email domains....
> 
> 
A mail admin does need to care *that* the service is located, and  
therefore will care *how* it is located.

You can be as theoretical as you like, by all means, but in practical  
terms, your email address (and my XMPP address) work because they use  
a defined, interoperable, service location mechanism, which operates  
via DNS record lookup.

(Also, I have no idea what multiple domains has to do with this.)


> Since WS is intended as a browser supported protocol, WS should  
> follow the
> same URI resolution mechanisms as HTTP (or how URI resolution is  
> done in
> general)  Having URLs that could resolve differently for a HTTP  
> request and
> a WS setup is a problem.
> 
> 
But they do resolve differently anyway. You don't get a page from a  
'ws' scheme URI, you get a transport protocol connection. This is  
good, indeed, it's kind of the point.

Your suggestion of "how URI resolution is done in general" is  
somewhat self-defeating, too, since aside from 'http' and 'https',  
there are 'mailto', which uses MX, 'sip' and 'xmpp', which both use  
SRV.

I think opponents of SRV records need to mount a stronger argument  
than the kind of luddite argument that if it's hard for one protocol  
in use by the browser, it should be hard for them all.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade