Re: [tsv-area] [tae] Transport negotiation
Bryan Ford <baford@mpi-sws.org> Sun, 14 December 2008 20:31 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 C58B93A67F4; Sun, 14 Dec 2008 12:31:27 -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 712BF3A67F4; Sun, 14 Dec 2008 12:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.779
X-Spam-Level:
X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 J5Wxx580NNAf; Sun, 14 Dec 2008 12:31:19 -0800 (PST)
Received: from apollo.mpi-sb.mpg.de (apollo.mpi-sb.mpg.de [139.19.1.50]) by core3.amsl.com (Postfix) with ESMTP id 734CC3A6782; Sun, 14 Dec 2008 12:31:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mpi-sb.mpg.de; s=mail200803; h=Cc:Message-Id:From:To: In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version: Subject:Date:References; bh=mujBhCGtD7LYh5MnpiL+yoq+TpzQHZGzkFnm LJXh1e8=; b=J3MUOqiGjl92XOlwYqDvJkIIjB0+9b/VV0E1HILZ8DiUHW1iUbm+ S711rjuC6FWd8Mfzlhu0ZcweoHNrGNhWwMANhCQssVIBgUlmHqnK2Yz2xZ53xati mfY7wkIMyLPYRWWhqjn21dx+OAVw14qGcVP5znxuPMJ9/F4gcCGWHQc=
Received: from infao0525.mpi-sb.mpg.de ([139.19.1.26]:50597 helo=newmaniac.mpi-sb.mpg.de) by apollo.mpi-sb.mpg.de (envelope-from <baford@mpi-sws.org>) with esmtp (Exim 4.69) id 1LBxc8-0000IS-GU; Sun, 14 Dec 2008 21:31:09 +0100
Received: from p54a594e9.dip0.t-ipconnect.de ([84.165.148.233]:55851 helo=[192.168.178.36]) by newmaniac.mpi-sb.mpg.de with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <baford@mpi-sws.org>) id 1LBxc7-0000fH-PJ; Sun, 14 Dec 2008 21:30:56 +0100
Message-Id: <6EFCD9EA-8050-4808-94E1-4CE16E2C36BB@mpi-sws.org>
From: Bryan Ford <baford@mpi-sws.org>
To: Lloyd Wood <L.Wood@surrey.ac.uk>
In-Reply-To: <4B36B0DC-54CC-4ADE-9688-074312E70E0D@surrey.ac.uk>
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: Sun, 14 Dec 2008 21:30:54 +0100
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> <4B36B0DC-54CC-4ADE-9688-074312E70E0D@surrey.ac.uk>
X-Mailer: Apple Mail (2.929.2)
Cc: tae@ietf.org, tsv-area@ietf.org, Joe Touch <touch@ISI.EDU>
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
On Dec 8, 2008, at 1:56 PM, Lloyd Wood wrote: > 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. I don't think transport protocol names belong in URLs, because transports are ultimately just tools that application protocols use to get stuff from point A to point B; the user doesn't usually and shouldn't have to care which tools the application uses to get its job done. Why should the user care whether his web browser is downloading his web page via HTTP-over-TCP or HTTP-over-SCTP? If the point of using SCTP is that it makes the parallel HTTP transfers go faster, then the behavior you want is that the client and server use SCTP whenever both client and server support it, and fall back to TCP otherwise. That behavior should be completely transparent to the end user - just like the negotiation of HTTP 1.0 versus HTTP 1.1 is - and should have no bearing on what an object is named. If you start encoding SCTP into URLs in web pages, then (as Iljitsch pointed out) things quickly start breaking as soon as the "http-over-sctp" URL reaches a client that doesn't support SCTP. While I'm not sure I would necessarly defend the "http" versus "https" distinction on architectural grounds, at least that distinction does have a direct bearing on the user - i.e., users often do care whether they're accessing a particular web site over a "secure" connection or not, and the "https" gives them a nice bit of warm fuzzy reassurance that they are. We might have already outgrown this approach, however, given that modern web browsers now much more loudly proclaim the secure/insecure status of web connections by changing the color of the URL bar and adding other fancy ornamentation; they could certainly still do those other things to tell the user whether the connection is secure or not, even if HTTP and HTTP-over-TLS actually shared the same URL scheme name and just negotiated security purely dynamically. > 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. This fact makes perverse sense when we keep in mind the historical reality that, as Joe Touch pointed out, the "http" scheme always in practice meant specifically "HTTP-(over-no-TLS-because-TLS-wasn't- there-yet)-over-TCP" - then it's clear what the port number means. But that doesn't mean we necessarily have to accept this state of affairs as the architectural Ten Commandments to apply for all time. If we try to move forward toward an architectural viewpoint where the "http:" scheme name means "HTTP-over-some-unknown-dynamically- negotiated-protocol-stack", it indeed becomes a little less obvious what exactly the attached "port number" field should mean. But we could envision generalizing it to be a transport-independent "service number" of some kind - or even, dare I say, a "service name"? Cheers, Bryan > 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> > > > > > > _______________________________________________ > tae mailing list > tae@ietf.org > https://www.ietf.org/mailman/listinfo/tae
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- [tsv-area] Transport negotiation Bryan Ford
- Re: [tsv-area] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation Janardhan Iyengar
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] Transport negotiation Lloyd Wood
- Re: [tsv-area] Transport negotiation Joe Touch
- Re: [tsv-area] Transport negotiation Lloyd Wood
- Re: [tsv-area] Transport negotiation Iljitsch van Beijnum
- Re: [tsv-area] [tae] Transport negotiation Stuart Cheshire
- Re: [tsv-area] [tae] Transport negotiation james woodyatt
- Re: [tsv-area] [tae] Transport negotiation james woodyatt
- Re: [tsv-area] [tae] Transport negotiation Iljitsch van Beijnum
- Re: [tsv-area] [tae] Transport negotiation james woodyatt
- Re: [tsv-area] [tae] Transport negotiation Lloyd Wood
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation Lloyd Wood
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation Stuart Cheshire
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation james woodyatt
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation Stuart Cheshire
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation Stuart Cheshire
- Re: [tsv-area] [tae] Transport negotiation james woodyatt
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation james woodyatt
- Re: [tsv-area] [tae] Transport negotiation Gorry Fairhurst
- Re: [tsv-area] [tae] Transport negotiation Iljitsch van Beijnum
- Re: [tsv-area] [tae] Transport negotiation Gorry Fairhurst
- Re: [tsv-area] [tae] Transport negotiation Iljitsch van Beijnum
- Re: [tsv-area] [tae] Transport negotiation Lloyd Wood
- Re: [tsv-area] [tae] Transport negotiation Lloyd Wood
- Re: [tsv-area] [tae] Transport checksum Gorry Fairhurst
- Re: [tsv-area] [tae] Transport negotiation Phelan, Tom
- Re: [tsv-area] [tae] Transport negotiation Iljitsch van Beijnum
- Re: [tsv-area] [tae] Transport negotiation Marshall Eubanks
- Re: [tsv-area] [tae] Transport negotiation Iljitsch van Beijnum
- Re: [tsv-area] [tae] Transport negotiation Phelan, Tom
- Re: [tsv-area] [tae] Transport negotiation james woodyatt
- Re: [tsv-area] [tae] Transport negotiation Stuart Cheshire
- Re: [tsv-area] [tae] Transport negotiation Joe Touch
- Re: [tsv-area] [tae] Transport negotiation Iljitsch van Beijnum
- Re: [tsv-area] [tae] Transport negotiation Bryan Ford
- Re: [tsv-area] [tae] Transport negotiation Bryan Ford
- [tsv-area] Host versus Endpoint Granularity (was … Bryan Ford
- Re: [tsv-area] [tae] Transport negotiation L.Wood
- Re: [tsv-area] [tae] Transport negotiation Joe Touch