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

Keith Moore <moore@network-heretics.com> Sat, 23 July 2011 23:25 UTC

Return-Path: <moore@network-heretics.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 117FE21F8ACA; Sat, 23 Jul 2011 16:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 7UEhchkEJuSb; Sat, 23 Jul 2011 16:25:06 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAC921F874E; Sat, 23 Jul 2011 16:25:06 -0700 (PDT)
Received: from [71.166.174.114] (helo=[10.59.1.76]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <moore@network-heretics.com>) id 1QklZ6-0006FO-Bo; Sat, 23 Jul 2011 19:25:00 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <20110723212322.3A6D1121E068@drugs.dv.isc.org>
Date: Sat, 23 Jul 2011 19:24:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B5A568C-0CEA-4143-8BC5-B9E721B7AB0A@network-heretics.com>
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> <4E28A51F.4020704@callenish.com> <20110723212322.3A6D1121E068@drugs.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1084)
X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940e151995611c2cbd95dd296b26078a1eb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 71.166.174.114
X-Mailman-Approved-At: Sat, 23 Jul 2011 16:27:26 -0700
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: Sat, 23 Jul 2011 23:25:07 -0000

On Jul 23, 2011, at 5:23 PM, Mark Andrews wrote:

> In message <4E28A51F.4020704@callenish.com>, Bruce Atherton writes:
>> 
>> I admit that I find it a little troubling to use MUST for the client to 
>> follow this procedure as there is a burden on implementers to understand 
>> how to code this since it isn't done by default in the standard 
>> libraries the way that ordinary name resolution is. Making it the 
>> recognized best practice with a SHOULD would be preferable all else 
>> being equal.
> 
> No.  MUST is what is needed.  It's a new protocol.  Do what's best from
> day one.


Sort of agree.  If use of SRV for this protocol is really appropriate (which I doubt, but I haven't looked at it closely) then the protocol specification should say "MUST use SRV".
If use of SRV for this protocol is not appropriate, or if it's not clear that it's appropriate, then the specification should probably say "MUST NOT use SRV". 

Either way, provide clear direction to implementors and don't leave the decision as to whether to use SRV up to the implementation.  That would create different behaviors in different implementations, which is clearly not desirable.

Keith