Re: [hybi] [Uri-review] ws: and wss: schemes

Maciej Stachowiak <mjs@apple.com> Wed, 12 August 2009 03:10 UTC

Return-Path: <mjs@apple.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE283A6875; Tue, 11 Aug 2009 20:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7Hu12TIitXr; Tue, 11 Aug 2009 20:10:46 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 9500F3A685C; Tue, 11 Aug 2009 20:10:46 -0700 (PDT)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 769EA715537C; Tue, 11 Aug 2009 20:09:19 -0700 (PDT)
X-AuditID: 11807130-b7bdfae000004bc9-db-4a82325f54f8
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id 59.7A.19401.F52328A4; Tue, 11 Aug 2009 20:09:19 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Received: from [10.0.1.6] (c-69-181-42-237.hsd1.ca.comcast.net [69.181.42.237]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KO8003P1U2VZJ00@elliott.apple.com>; Tue, 11 Aug 2009 20:09:19 -0700 (PDT)
Message-id: <87FF3009-5686-43ED-9A64-16D41FE27990@apple.com>
From: Maciej Stachowiak <mjs@apple.com>
To: David Booth <david@dbooth.org>
In-reply-to: <1250045546.3990.1906.camel@dbooth-laptop>
Date: Tue, 11 Aug 2009 20:08:54 -0700
References: <Pine.LNX.4.62.0908070531430.28566@hixie.dreamhostps.com> <1249651007.25446.8934.camel@dbooth-laptop> <4A7CD53D.13936.1264B606@dan.tobias.name> <1249869122.20315.388.camel@dbooth-laptop> <4E34F2AF-C737-4A7D-AD9F-07AD177313BA@apple.com> <1250045546.3990.1906.camel@dbooth-laptop>
X-Mailer: Apple Mail (2.936)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: "Daniel R. Tobias" <dan@tobias.name>, uri-review@ietf.org, hybi@ietf.org, uri@w3.org
Subject: Re: [hybi] [Uri-review] ws: and wss: schemes
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 12 Aug 2009 03:10:47 -0000

On Aug 11, 2009, at 7:52 PM, David Booth wrote:

> On Tue, 2009-08-11 at 17:23 -0700, Maciej Stachowiak wrote:
>> On Aug 9, 2009, at 6:52 PM, David Booth wrote:
>>
>>>
>>> I can't see that as a significant issue, as there is only a trivial
>>> difference between dispatching based on the string prefix
>>> "http://wss.example/" and the string prefix "wss:".  Both are  
>>> simple,
>>> constant strings and both are equally "magic": they cause agent to
>>> attempt the WSS protocol.
>>
>> The difference is that "http://wss.example/" already has a meaning,
>> which is not the intended one. Whereas "wss:" currently has no
>> meaning. Thus the former has greater risk of either colliding with an
>> existing resource, or being misinterpreted by a legacy client  
>> (instead
>> of just rejected).
>
> That's not a risk, that's the *intent*.  The point is that a prefix  
> like
> "http://wss.example/" gives agents that do not know the WSS protocol  
> the
> possibility of doing something useful with the URI, by falling back to
> the HTTP protocol, whereas if a prefix like "wss:" were used those  
> same
> agents would have to reject it entirely.  The "http://wss.example/"  
> URI
> still retains its meaning as an http URI, but it gains *additional*
> meaning as a WSS URI for those agents that know how to handle the WSS
> protocol.

I do not believe it is an advantage for new clients to retroactively  
reinterpret existing http resources as wss resources. There exist  
hosts whose name starts with "wss", so this seems inevitable. This  
seems like a clear disadvantage.

I also do not believe it is an advantage for legacy clients to  
dereference wss: hosts via http; it hypothetically sounds neat but I  
cannot think of a use case where it would actually be beneficial. This  
is not necessarily a disadvantage, but it doesn't seem like much of an  
advantage either.

Finally, I do not think hosting a WebSocket service should require  
having a host set up with "wss" at the start of the name. Parties  
deploying WebSocket services may be in control of their own DNS  
namespace, so this is an onerous requirement. That seems like a clear  
disadvantage of your scheme.

In conclusion, I think your proposal is idiosyncratic, and not a good  
fit for the WebSocket protocol.

Regards,
Maciej