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

David Endicott <> Thu, 21 July 2011 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED90A21F87E2; Thu, 21 Jul 2011 11:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cUwra0JX8Xbw; Thu, 21 Jul 2011 11:43:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B14BC21F8786; Thu, 21 Jul 2011 11:43:08 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1041893wwe.13 for <multiple recipients>; Thu, 21 Jul 2011 11:43:07 -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; bh=UohUz9bZaoYlcN1uxhHQWDuv6A0R8kjPZYf9UMaBHzg=; b=q2lOB8/1Dx3S7/nHDu/RQFjd+FRx+4uVPnIS0WE+0S1ng9icv3bxtmzwYlNDuxYihO oDshworcR8/5CRH8sGaPWdggGZPqd+Y1UOKeJx63CAlhHX3xtwIz6zxVQq+LNpfOwO/e xvjBlTzMb8ORv+mfVhdWtOpkJXcj1OCROrGHE=
MIME-Version: 1.0
Received: by with SMTP id 50mr1215331wed.33.1311273787757; Thu, 21 Jul 2011 11:43:07 -0700 (PDT)
Received: by with HTTP; Thu, 21 Jul 2011 11:43:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <9031.1311082001.631622@puncture> <> <> <> <> <> <9031.1311270000.588511@puncture> <> <> <>
Date: Thu, 21 Jul 2011 14:43:07 -0400
Message-ID: <>
From: David Endicott <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: multipart/alternative; boundary=0016364d2c795297c804a898b8e9
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 18:43:18 -0000

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

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.

However....I agree in the sense that I don't think it's been well thought
out what the ramifications are of introducing a new URI *scheme*.  (ie.
ws:// and wss://)    Since everything after the double-slash is "scheme
specific", defining a scheme implies many things (including name resolution
policies, well-known ports, transport protocols, etc.)   But, I don't want
to get side tracked over this.

On Thu, Jul 21, 2011 at 2:10 PM, Iñaki Baz Castillo <> wrote:

> 2011/7/21 David Endicott <>om>:
> > I am strongly opposed to any MUST definition for any type of URL
> resolution.
> SIP and XMPP mandate (MUST) a resolution mechanism based on NAPTR, SRV
> and A/AAAA records. Are they also wrong? do you also oppose to the DNS
> MX resolution (as mandatory) for a mailto: URI? Do you imagine that a
> mail server admin could not assume that SMTP clients would always use
> MX resolution as the first choice? annoying that you say that, sorry.
> > I'm ok with inheriting / mimicking HTTP.    Since it is intended to live
> in
> > the same universe as HTTP, I'm ok with it sharing mechanisms /
> limitations.
> Yes, I assume many people in the HTTP warden is fine with this. That
> is the problem: forcing a *new* protocol to inherit ugly limitations
> just because "people is used to them". I don't understand how you can
> prefer to ignore cool NEW solutions/mechanisms. This should not be a
> valid argument in a new protocol design.
> --
> Iñaki Baz Castillo
> <>