Re: [tsv-area] [tae] Transport negotiation

Lloyd Wood <L.Wood@surrey.ac.uk> Mon, 08 December 2008 12:57 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 AE6AC28C0F6; Mon, 8 Dec 2008 04:57:05 -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 C1DBE3A6A9A; Mon, 8 Dec 2008 04:57:03 -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=[AWL=0.000, 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 bnQ63pJ3Unz3; Mon, 8 Dec 2008 04:57:02 -0800 (PST)
Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id 3CBF53A6784; Mon, 8 Dec 2008 04:57:02 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-7.tower-82.messagelabs.com!1228741015!82682982!3
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 13387 invoked from network); 8 Dec 2008 12:56:56 -0000
Received: from unknown (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-7.tower-82.messagelabs.com with SMTP; 8 Dec 2008 12:56:56 -0000
Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Dec 2008 12:56:49 +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); Mon, 8 Dec 2008 12:56:48 +0000
Message-Id: <4B36B0DC-54CC-4ADE-9688-074312E70E0D@surrey.ac.uk>
From: Lloyd Wood <L.Wood@surrey.ac.uk>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <493CB9D3.2080308@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: Mon, 08 Dec 2008 12:56:47 +0000
References: <3BB334D8-B00C-48C1-ACBF-4D09576DEADF@mpi-sws.org> <492C7F97.3030000@isi.edu> <EDCC4CF2-DC3C-409F-8F99-3BE51BAE4111@surrey.ac.uk> <492DE8AD.1090300@isi.edu> <7DA33930-1767-492B-807E-7A7DA661AFE9@apple.com> <EAB5CBF0-4C7A-44F1-BF57-641915CBE6AB@surrey.ac.uk> <493CB9D3.2080308@isi.edu>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 08 Dec 2008 12:56:48.0461 (UTC) FILETIME=[6E8BFFD0:01C95934]
Cc: tae@ietf.org, tsv-area@ietf.org
Subject: Re: [tsv-area] [tae] 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

Joe,

I'm interested in a parseable way to pass that information down from a  
URI and the program handling the URI.

Right now, we can explicitly state 'http' or 'https'. These are  
presumed to live over TCP, and IP - whether to use v4 or v6 is usually  
determined directly by giving an address or by DNS. But, oddly enough,  
we can also explicitly specify the port number, which defaults to 80.  
So, even though http lives on port 80 (and https on 443), that can be  
overridden in the URI.

Similarly, though http is expected to live over TCP, being able to  
explicitly override it in the URI if desired has merit in some cases.  
That is, 'http' would be the same as writing 'http-tcp'. 'http-sctp',  
for the work outlined in:
http://tools.ietf.org/html/draft-natarajan-http-over-sctp
means use a different transport - SCTP instead of TCP.

Doesn't it strike you as odd that we can, at a high uri level, specify  
the low-level port number, but not the details of the layering to be  
used for that port? By adding explicit detail in the URI, we are  
removing ambiguity.

L.


On 8 Dec 2008, at 06:08, Joe Touch wrote:
>
> Lloyd Wood wrote:
>>
>> On 3 Dec 2008, at 21:07, Stuart Cheshire wrote:
>>>
>>> I think the whole notion of "transport negotiation" is flawed.
>>
>> agreed. And moving negotiation to 'asking DNS what to do' is just
>> shifting the problem around.
>>
>> At the least, it should be possible to explicitly say 'this is how I
>> will send' and presume the other end is similarly explicitly  
>> configured.
>> No negotiation, period.
>
> Isn't that exactly what happens when I send a TCP over IPv4 SYN  
> segment?
> I'm saying "I want to use IPv4, using TCP, with the indicated options,
> on the given port".
>
> The trouble ensues when the initiator is ambiguous about what it  
> wants -
> for whatever reason (e.g., to enable alternates at differently-capable
> receivers).
>
> Joe

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>