Re: [core] Link to multicast http I-D

<L.Wood@surrey.ac.uk> Wed, 29 September 2010 16:34 UTC

Return-Path: <L.Wood@surrey.ac.uk>
X-Original-To: core@core3.amsl.com
Delivered-To: core@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9763A6BB0 for <core@core3.amsl.com>; Wed, 29 Sep 2010 09:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level:
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EZtzN7dReJ3J for <core@core3.amsl.com>; Wed, 29 Sep 2010 09:34:30 -0700 (PDT)
Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id E08123A6D24 for <core@ietf.org>; Wed, 29 Sep 2010 09:34:29 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-11.tower-82.messagelabs.com!1285778111!22013892!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.200.35]
Received: (qmail 28405 invoked from network); 29 Sep 2010 16:35:11 -0000
Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-11.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 29 Sep 2010 16:35:11 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.245]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Wed, 29 Sep 2010 17:35:10 +0100
From: L.Wood@surrey.ac.uk
To: kerlyn2001@gmail.com
Date: Wed, 29 Sep 2010 17:35:11 +0100
Thread-Topic: [core] Link to multicast http I-D
Thread-Index: Actf8rjTIAN00MXqQv6wdrPuMOidMwAAKmjw
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A3730C2D62BBA1@EXMB01CMS.surrey.ac.uk>
References: <AANLkTimFTkHSZ73npFmGHczupt7as77PKR2QwxXbiB_c@mail.gmail.com> <FD7B10366AE3794AB1EC5DE97A93A3730C2D62BB9A@EXMB01CMS.surrey.ac.uk> <AANLkTinzsJkhAZiCQDgBQj9=KhNUAQUqwNKZ0x9GB1o0@mail.gmail.com>
In-Reply-To: <AANLkTinzsJkhAZiCQDgBQj9=KhNUAQUqwNKZ0x9GB1o0@mail.gmail.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: core@ietf.org
Subject: Re: [core] Link to multicast http I-D
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2010 16:34:39 -0000

"multicast resource manipulation" is not a topic per se.

HTTP-DTN was proposed as running over Saratoga (UDP + necessary reliability for large files and resend) and Saratoga supports multicast.
http://tools.ietf.org/html/draft-wood-tsvwg-saratoga

You might also look into DDS, which is publish/subscribe CORBA middleware that does resource management and claims support of multicast as one of its transports.

http://www.opendds.org/transport.html
http://en.wikipedia.org/wiki/Data_Distribution_Service

-----Original Message-----
From: Kerry Lynn [mailto:kerlyn2001@gmail.com] 
Sent: 29 September 2010 17:24
To: Wood L Dr (Electronic Eng)
Cc: core@ietf.org
Subject: Re: [core] Link to multicast http I-D
Importance: High

Do any of this work specifically address the topic of multicast resource manipulation?

-K-

On Wed, Sep 29, 2010 at 12:18 PM,  <L.Wood@surrey.ac.uk> wrote:
> The Goland draft mentioned below is a ten-year-old proposal.
>
> Rather more useful and general than trying to specify http over UDP is breaking http from TCP as a separate layer, and then putting it over a variety of reliable transports, be they UDP-based, SCTP, TCP or otherwise.
>
> Some notes on this and various pieces of work in this area are at:
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-
> drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into
> -a-standalone-layer-ietf-75-tsvarea-slides.pdf
> Turning HTTP into a standalone layer: decoupling HTTP from TCP, talk given to the TSVAREA meeting, IETF 75, Stockholm, 27 July 2009.
>
> and on
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn
>
> delay-tolerant networking (DTN) provided a motivation for separating HTTP from TCP for environments where TCP fails, but the overall need to treat HTTP as a separate layer remains; just ignore the DTN-forwarding-specific Content- headers.
>
> (meanwhile, Joe Touch would be interested in getting BGP off of only 
> TCP, and onto e.g. SCTP... again, breaking coupling between layers in 
> implementations with greater use of layering. HTTP really is a layer 
> in its own right, and should be able to run over any reliable 
> transport.)
>
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf 
> Of Kerry Lynn
> Sent: 29 September 2010 17:10
> To: core
> Subject: [core] Link to multicast http I-D
>
> http://tools.ietf.org/html/draft-goland-http-udp-01
>
> -K-
>