Re: [tsv-area] Transport negotiation

Lloyd Wood <L.Wood@surrey.ac.uk> Thu, 27 November 2008 00:04 UTC

Return-Path: <tsv-area-bounces@ietf.org>
X-Original-To: tsv-area-archive@optimus.ietf.org
Delivered-To: ietfarch-tsv-area-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442AD3A6967; Wed, 26 Nov 2008 16:04:57 -0800 (PST)
X-Original-To: tsv-area@core3.amsl.com
Delivered-To: tsv-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A433A6967; Wed, 26 Nov 2008 16:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 mWtorFqBe5fq; Wed, 26 Nov 2008 16:04:55 -0800 (PST)
Received: from mail133.messagelabs.com (mail133.messagelabs.com [195.245.230.179]) by core3.amsl.com (Postfix) with SMTP id A532A3A67AF; Wed, 26 Nov 2008 16:04:54 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-14.tower-133.messagelabs.com!1227744288!29629264!2
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 14373 invoked from network); 27 Nov 2008 00:04:48 -0000
Received: from unknown (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-14.tower-133.messagelabs.com with SMTP; 27 Nov 2008 00:04:48 -0000
Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 00:04:46 +0000
Received: from [192.168.1.209] ([86.3.93.24]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 00:04:46 +0000
Message-Id: <EDCC4CF2-DC3C-409F-8F99-3BE51BAE4111@surrey.ac.uk>
From: Lloyd Wood <L.Wood@surrey.ac.uk>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <492C7F97.3030000@isi.edu>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 27 Nov 2008 00:04:45 +0000
References: <3BB334D8-B00C-48C1-ACBF-4D09576DEADF@mpi-sws.org> <492C7F97.3030000@isi.edu>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 27 Nov 2008 00:04:46.0459 (UTC) FILETIME=[C1F02CB0:01C95023]
Cc: Bryan Ford <baford@mpi-sws.org>, tae@ietf.org, tsv-area@ietf.org
Subject: Re: [tsv-area] Transport negotiation
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
Sender: tsv-area-bounces@ietf.org
Errors-To: tsv-area-bounces@ietf.org

On 25 Nov 2008, at 22:43, Joe Touch wrote:
> Right. The trick is that there is no such thing as HTTP; it's HTTP  
> over
> TCP. What you want is "HTTP by any means"; whether the DNS supports  
> this
> is less the issue than the fact that IANA doesn't really define such a
> thing.

Worth mentioning a couple of drafts contemplating HTTP running over
something other than TCP:
Preethi Natarajan's HTTP over SCTP, with modifications to Apache,  
which got talked about in Minneapolis:
http://tools.ietf.org/html/draft-natarajan-http-over-sctp

Our proposal to use HTTP for peer-to-peer rather than client-server
transfers, and to layer it over whatever transport is suitable for
the local environment:

http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
(presented at IETF 71 in Philadelphia.)

I'd be interested in knowing of other, similar, work and seeing
what commonalities there are.

On choosing transport, couldn't http:// just map to http/<whatever-is- 
favoured>:// ?

Explicitly asking for http/tcp:// or http/sctp:// would produce
different behaviour. I don't see a need to involve DNS here -
but I'd quite like to be able to specify http/tcp/ipv6:// or
http/sctp/ipv4:// to force behaviour in the browser, while
knowing that http:// just works.

L.

introducing the world's surfers to layering is just a bonus.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>