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

Philippe Bernard <> Thu, 21 July 2011 21:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8536721F8ADC; Thu, 21 Jul 2011 14:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1QMACVSny1si; Thu, 21 Jul 2011 14:52:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9127D21F898E; Thu, 21 Jul 2011 14:52:35 -0700 (PDT)
Received: by pvh18 with SMTP id 18so2046036pvh.31 for <multiple recipients>; Thu, 21 Jul 2011 14:52:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vyN7eX/XeuNubz6FtZKzzl2CbZWFykNGkZEEKDHGXNU=; b=JDwqhSKmcWvhlwQGa0quutAOUmNtr+sE0v3WxR+DmVXbZTdWbv+qr/D8oEA7MhiTst jmjF9xszQJxG45WSuNXayREIB6fadZak9bTiTd4PWRgs52xhYCTfzxkRORvaZRDu4mS+ uC3ZETyzYCGGOJq5poA0pzAjYeobcI+L2gSXk=
MIME-Version: 1.0
Received: by with SMTP id b3mr1082144pbl.164.1311285155267; Thu, 21 Jul 2011 14:52:35 -0700 (PDT)
Received: by with HTTP; Thu, 21 Jul 2011 14:52:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <9031.1311270000.588511@puncture> <> <> <> <> <9031.1311279546.247694@puncture> <>
Date: Thu, 21 Jul 2011 22:52:35 +0100
Message-ID: <>
From: Philippe Bernard <>
To: David Endicott <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP <>, IETF-Discussion <>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jul 2011 21:52:42 -0000

On Thu, Jul 21, 2011 at 9:57 PM, David Endicott <> wrote:
>> 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.

Iñaki's proposal only imposes a requirement on clients, not on
server-side WS deployments, since clients will fall back to A/AAAA if
no SRV records are available. The mechanism (on the client-side)
cannot be optional though, it would make SRV for WS mostly useless in


>> Dave.
>> --
>> Dave Cridland - -
>>  - acap://
>>  -
>> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
> _______________________________________________
> hybi mailing list