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

David Endicott <dendicott@gmail.com> Thu, 21 July 2011 20:57 UTC

Return-Path: <dendicott@gmail.com>
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 F3A1421F86BD; Thu, 21 Jul 2011 13:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.568
X-Spam-Level:
X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yMgaAcXLVagu; Thu, 21 Jul 2011 13:57:26 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4F0D21F86A8; Thu, 21 Jul 2011 13:57:25 -0700 (PDT)
Received: by wyj26 with SMTP id 26so1269260wyj.31 for <multiple recipients>; Thu, 21 Jul 2011 13:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LgsmM44IFtoalDLCWx5puGABu3s2MD+CIDZuKt5geWo=; b=kTGvlAZ7EkSJXZrSsWx3SYJiPRWAJ42Ec1ZyAWjoPctZB6i97JBFwRFtljkzdoVPeK 40ns1NpUGUgvRo4laUIkI3uQ79QmmhZbiH18bgxwOIgNRnlr9ZuFZpsmWfJmx4y/r7dY KEu/cRxjHfx1joMsA/qK+bXYrqjP+DR//OYCE=
MIME-Version: 1.0
Received: by 10.216.234.209 with SMTP id s59mr649447weq.18.1311281844964; Thu, 21 Jul 2011 13:57:24 -0700 (PDT)
Received: by 10.216.39.197 with HTTP; Thu, 21 Jul 2011 13:57:23 -0700 (PDT)
In-Reply-To: <9031.1311279546.247694@puncture>
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> <9031.1311279546.247694@puncture>
Date: Thu, 21 Jul 2011 16:57:23 -0400
Message-ID: <CAP992=Ec3KvAerosLNkJCTNzFniRfU-bFg_7=bAiMOJFarb5zA@mail.gmail.com>
From: David Endicott <dendicott@gmail.com>
To: Dave Cridland <dave@cridland.net>
Content-Type: multipart/alternative; boundary=001517592bd091cf6f04a89a9883
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: Thu, 21 Jul 2011 20:57:28 -0000

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

That's what I meant.  XMPP systems have hosts that change around (for many
reasons) and having a name resolution that handles that is good.



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


Yes, those are all excellent reasons to use DNS SRV.   None of them are a
reason to mandate that WS require it.   Because something is good for some
(or many) use cases, does not mean it is appropriate for everything and
certainly is not a reason to mandate it as a requirement.
 System implementer should be free to pick and choose tools and mechanisms
appropriate for their tasks.   DNS SRV would likely be an excellent choice
for many people.   But it should not be the one and only choice.   That's
really all I'm saying - don't force people to use something without an
overwhelming reason to make it the only option.



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


Imagine I'm a SMTP server.   People connect to me.   They do SMTP
transactions.    I do not care how they found me.   Perhaps they used DNS to
find the MX server.  Perhaps they had it cached from before.  Perhaps they
guessed.  Perhaps it's in a hosts file.   I don't care.     I answer VRFY
and RCPT TO commands as appropriate.   If the "name" they are trying to
mailwith is one I recognize, I process it.  If I don't, it's an error.
Just because DNS-MX said that @foobar was handled at <addr>, doesn't mean
the dave@foobar is going to work.

Yes, DNS MX is a well known mechanism for determining what SMTP server to
connect with, but like I tried to say above, it's not mandated by the SMTP
protocol.   DNS MX is independent of SMTP and the two mechanisms
operate separately, but with a common goal.  I can use DNS to resolve a name
and never send email/message.  I can send a email/message via SMTP and never
use DNS to resolve a name.    Or I can use one to do the other.

When a SMTP server handles mail for multiple domains, the SMTP server has to
process the @domain part of the RCPT TO request - DNS is not involved at
that point.   This process is unrelated to any DNS MX definitions.    I used
that as an example of how some name resolutions are sometimes done outside
of any DNS framework.



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

Do they?   A http uri and a ws uri have the same host/path construction.
 It's really only the scheme that differs - and that identifies the
transport protocol to be used.   Resolution of host name/addresses and
mapping of paths "should" be consistent.

WS is a connection that is semantically related to the URI of the request.


e.g. I could ws://host/davesaid  and get live traffic of what Dave is
saying, and then I could ws://host/bobsaid  and get traffic of what Bob
says.  I wouldn't get Bob on /davesaid and I wouldn't get Dave on /bobsaid.
   Dynamic content identified by a URI

And if I http://host/davesaid  I could get a <li> of what Dave said.
Static content of a URI.

It could be problematic if  ws://host/davesaid resolves to a different
address than http://host/davesaid.     (Or it could be advantage - not for
us to decide, however)


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

As you just said, the universe is bigger than just xmpp, sip, and http.

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


I think you misinterpret my position.  And I resent the luddite slight.   I
think DNS SRV is an awesome tool and would greatly benefit many
implementations.

My position is that it should not be a *requirement*.     It should be an
optional mechanism that can be used if desired.   Further, since WS is a
bastard cousin to HTTP, they should share a similar name resolution
mechanism.



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