Re: [hybi] Apples and Orangutans

Maciej Stachowiak <mjs@apple.com> Sun, 12 April 2009 22:38 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 009973A68A3 for <hybi@core3.amsl.com>; Sun, 12 Apr 2009 15:38:50 -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 0JYqCN+EDRfL for <hybi@core3.amsl.com>; Sun, 12 Apr 2009 15:38:49 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 4B61F3A682A for <hybi@ietf.org>; Sun, 12 Apr 2009 15:38:49 -0700 (PDT)
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id C47C15EC6E80 for <hybi@ietf.org>; Sun, 12 Apr 2009 15:39:59 -0700 (PDT)
Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Brightmail Gateway) with ESMTP id ADF4428083 for <hybi@ietf.org>; Sun, 12 Apr 2009 15:39:59 -0700 (PDT)
X-AuditID: 11807134-a5855bb000000ff0-66-49e26dbf6c38
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with ESMTP id 8A9E12802F for <hybi@ietf.org>; Sun, 12 Apr 2009 15:39:59 -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.7] (c-69-181-43-20.hsd1.ca.comcast.net [69.181.43.20]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KI000H0DEYML030@et.apple.com> for hybi@ietf.org; Sun, 12 Apr 2009 15:39:59 -0700 (PDT)
Message-id: <71289452-5A19-48F4-9819-7FD9747EE9CA@apple.com>
From: Maciej Stachowiak <mjs@apple.com>
To: Ian Hickson <ian@hixie.ch>
In-reply-to: <Pine.LNX.4.62.0904122230550.10339@hixie.dreamhostps.com>
Date: Sun, 12 Apr 2009 15:39:58 -0700
References: <49DEF171.4080506@mozilla.com> <A3699591-148C-4795-967A-6CDE23FE75F0@apple.com> <Pine.LNX.4.62.0904122230550.10339@hixie.dreamhostps.com>
X-Mailer: Apple Mail (2.930.3)
X-Brightmail-Tracker: AAAAAA==
Cc: hybi@ietf.org
Subject: Re: [hybi] Apples and Orangutans
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: Sun, 12 Apr 2009 22:38:50 -0000

On Apr 12, 2009, at 3:35 PM, Ian Hickson wrote:

> On Sun, 12 Apr 2009, Maciej Stachowiak wrote:
>>
>> I like Minimal/Event too, although I am starting to think the  
>> WebSocket
>> protocol may be a bit too minimal. I think adding an optional type  
>> field
>> to the packet or to the initial negotiation would help independently
>> developed client and server code coordinate, much in the way MIME  
>> types
>> help HTTP clients and servers without the necessity to define every
>> possible type up front or to couple a single client to a single  
>> server.
>> [...] TCP includes a port number (associated with protocols by
>> convention)
>
> WebSocket includes a path (from the ws:// URL), which is intended to  
> be
> analogous to the TCP port number.
>
> Does that address this particular point satisfactorily?

I'm not sure the path is a good choice for identifying the type of  
service available. HTTP has both a path and a type. The path is sent  
by the client and identifies the specific resource. The type is sent  
by the server and directs how the resource is to be interpreted. I do  
not think we can expect, for example, multiple chat services to use  
the same path format, but there may be multiple chat services which  
choose to use the same protocol-by-convention over WebSocket. Right  
now, there doesn't seem to be a good way to give this information to  
the client, in the same way that any arbitrary URL can tell the client  
that its contents are to be interpreted as XML or PDF or plain text.

Regards,
Maciej