Re: [tsv-area] TSVAREA presentation slots for Stockholm

Lloyd Wood <L.Wood@surrey.ac.uk> Fri, 05 June 2009 17:40 UTC

Return-Path: <L.Wood@surrey.ac.uk>
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 51C2A3A6D8F for <tsv-area@core3.amsl.com>; Fri, 5 Jun 2009 10:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.729
X-Spam-Level:
X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87]
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 48x0mWohu--z for <tsv-area@core3.amsl.com>; Fri, 5 Jun 2009 10:40:16 -0700 (PDT)
Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with SMTP id CF91A3A6DAD for <tsv-area@ietf.org>; Fri, 5 Jun 2009 10:40:15 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-8.tower-72.messagelabs.com!1244223615!60098613!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 10098 invoked from network); 5 Jun 2009 17:40:15 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-8.tower-72.messagelabs.com with SMTP; 5 Jun 2009 17:40:15 -0000
Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 18:40:15 +0100
Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 18:40:14 +0100
Message-Id: <A3EEA6A1-DBA8-4167-B53D-7866C6D54A53@surrey.ac.uk>
From: Lloyd Wood <L.Wood@surrey.ac.uk>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A295485.3010800@isi.edu>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Fri, 05 Jun 2009 18:40:14 +0100
References: <XFE-SJC-211o8yfogkJ0000099d@xfe-sjc-211.amer.cisco.com> <021CFFF8-0F8C-4653-878B-EC2CD7996B9F@nokia.com> <4835AFD53A246A40A3B8DA85D658C4BE7B1041@EVS-EC1-NODE4.surrey.ac.uk> <3C661972-A567-4F11-9E27-66FF4AB15872@muada.com> <294EB9DE-B5BB-449E-8C68-0AEF579EA286@surrey.ac.uk> <C304DB494AC0C04C87C6A6E2FF5603DB2216730037@NDJSSCC01.ndc.nasa.gov> <324A28AF-D429-42BE-8643-9CAFF23BD5F8@muada.com> <392B7A70-A69C-47B1-B7E6-CBF874D3ABCA@surrey.ac.uk> <4A293196.8040005@isi.edu> <DDE030A4-26B2-4F80-8511-B9F0818E664E@surrey.ac.uk> <4A2947BA.9040800@isi.edu> <E0E771DD-3BFC-4F45-A49B-DC2753EAE231@surrey.ac.uk> <4A295485.3010800@isi.edu>
X-Mailer: Apple Mail (2.935.3)
X-OriginalArrivalTime: 05 Jun 2009 17:40:15.0135 (UTC) FILETIME=[AF41C2F0:01C9E604]
Cc: TSV Area <tsv-area@ietf.org>
Subject: Re: [tsv-area] TSVAREA presentation slots for Stockholm
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/mail-archive/web/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>
X-List-Received-Date: Fri, 05 Jun 2009 17:40:17 -0000

On 5 Jun 2009, at 18:23, Joe Touch wrote:
> Lloyd Wood wrote:
>>
>> On 5 Jun 2009, at 17:28, Joe Touch wrote:
>>> Lloyd Wood wrote:
>>>>
>>>> On 5 Jun 2009, at 15:54, Joe Touch wrote:
>>>>> Lloyd Wood wrote:
>>>>> ...
>>>>>> Do the internals of TCP change when it's running over IPv4 vs  
>>>>>> IPv6?
>>>>>> Does the interface to upper layers change?
>>>>>
>>>>> Actually, yes - the pseudoheader over which the checksum is  
>>>>> computed
>>>>> channges. So too does ICMP signalling, setting of the DF bit for
>>>>> fragmentation discovery (clearing it doesn't have the same  
>>>>> effect in v6
>>>>> as in v4), etc.
>>>>
>>>> ...so, by analogy, there's likely a need to describe HTTP over  
>>>> different
>>>> transports, what is different, and what changes.
>>>
>>> Yes - I thought that's where they were going with the SCTP stuff.
>>
>> Right. But are there more general 'HTTP over transport X' rules or
>> conventions that need to be described?
>
> I'd hope that a general decoupling would be useful, then a set of
> mappings, one for each transport. That sort of regularity hasn't been
> common - either in the IETF as a whole or in the past evolution of  
> HTTP,
> though ;-)
>
> Are we trying to encourage them to do that, or just overseeing how it
> evolves?

Neither. We're interested in using the result, even if we have
to describe it ourselves.

http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf

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>