Re: [tsv-area] [tae] Transport negotiation
<L.Wood@surrey.ac.uk> Mon, 15 December 2008 15:13 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 802673A6A0A; Mon, 15 Dec 2008 07:13:51 -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 C48063A67F0; Mon, 15 Dec 2008 07:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wUh-z0bOTAmE; Mon, 15 Dec 2008 07:13:47 -0800 (PST)
Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id B06393A69F2; Mon, 15 Dec 2008 07:13:46 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-10.tower-82.messagelabs.com!1229354016!67419375!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 12566 invoked from network); 15 Dec 2008 15:13:37 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-10.tower-82.messagelabs.com with SMTP; 15 Dec 2008 15:13:37 -0000
Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.139]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 15:13:36 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95EC7.B3B688F5"
Date: Mon, 15 Dec 2008 15:11:59 -0000
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B0DD5@EVS-EC1-NODE4.surrey.ac.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tae] [tsv-area] Transport negotiation
Thread-Index: AcleKuoUCcbVpmNyRX+B/9HIqnh3LwAnI+hv
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> <6EFCD9EA-8050-4808-94E1-4CE16E2C36BB@mpi-sws.org>
From: L.Wood@surrey.ac.uk
To: baford@mpi-sws.org
X-OriginalArrivalTime: 15 Dec 2008 15:13:36.0627 (UTC) FILETIME=[B3E2FC30:01C95EC7]
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
Bryan, I've written up http://www.ietf.org/internet-drafts/draft-wood-tae-specifying-uri-transports-00.txt which should answer your "why should the user care?" question below. cheers, L. <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk> -----Original Message----- From: Bryan Ford [mailto:baford@mpi-sws.org] Sent: Sun 2008-12-14 20:30 To: Wood L Dr (Electronic Eng) Cc: Joe Touch; tae@ietf.org; tsv-area@ietf.org Subject: Re: [tae] [tsv-area] Transport negotiation 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