IETF Logo Mail Archive

Re: Range Responses of Indeterminate Length: Draft

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Tue, 07 April 2015 07:43 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8351B32A3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Apr 2015 00:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level:
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86p3zKbaG3L5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Apr 2015 00:43:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765BB1B32A9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 7 Apr 2015 00:43:42 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YfO7b-0006H1-Pl for ietf-http-wg-dist@listhub.w3.org; Tue, 07 Apr 2015 07:40:31 +0000
Resent-Date: Tue, 07 Apr 2015 07:40:31 +0000
Resent-Message-Id: <E1YfO7b-0006H1-Pl@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <duerst@it.aoyama.ac.jp>) id 1YfO7X-0006Ey-Uy for ietf-http-wg@listhub.w3.org; Tue, 07 Apr 2015 07:40:27 +0000
Received: from mail-hk1bn0107.outbound.protection.outlook.com ([134.170.140.107] helo=APAC01-HK1-obe.outbound.protection.outlook.com) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <duerst@it.aoyama.ac.jp>) id 1YfO7W-0004It-6k for ietf-http-wg@w3.org; Tue, 07 Apr 2015 07:40:27 +0000
Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0144.jpnprd01.prod.outlook.com (25.161.134.148) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 7 Apr 2015 07:38:29 +0000
Message-ID: <55238972.3020108@it.aoyama.ac.jp>
Date: Tue, 07 Apr 2015 16:38:26 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>, Rodger Combs <rodger@plexapp.com>
CC: ietf-http-wg@w3.org
References: <F755B212-3186-493F-B298-E529A2502467@plex.tv> <DF498B3A-90B7-4D30-88EA-E312B06F9BC4@mnot.net>
In-Reply-To: <DF498B3A-90B7-4D30-88EA-E312B06F9BC4@mnot.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [133.2.210.64]
X-ClientProxiedBy: OS2PR01CA0007.jpnprd01.prod.outlook.com (25.161.74.145) To TY1PR01MB0144.jpnprd01.prod.outlook.com (25.161.134.148)
Authentication-Results: w3.org; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0144;
X-Microsoft-Antispam-PRVS: <TY1PR01MB01442831AB33582D7CFBC0D4CAFD0@TY1PR01MB0144.jpnprd01.prod.outlook.com>
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(6049001)(51704005)(479174004)(377454003)(24454002)(164054003)(83506001)(76176999)(65816999)(54356999)(87266999)(86362001)(47776003)(50986999)(42186005)(19580405001)(66066001)(23676002)(19580395003)(87976001)(85182001)(92566002)(2950100001)(59896002)(62966003)(77156002)(65956001)(65806001)(40100003)(64126003)(117636001)(74482002)(122386002)(50466002)(46102003)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0144; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(5002010); SRVR:TY1PR01MB0144; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0144;
X-Forefront-PRVS: 0539EEBD11
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2015 07:38:29.6011 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0144
Received-SPF: pass client-ip=134.170.140.107; envelope-from=duerst@it.aoyama.ac.jp; helo=APAC01-HK1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-6.9
X-W3C-Hub-Spam-Report: AWL=0.096, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1YfO7W-0004It-6k 9771690a84ba8c9fea73d94dbd34fde0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Range Responses of Indeterminate Length: Draft
Archived-At: <http://www.w3.org/mid/55238972.3020108@it.aoyama.ac.jp>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/29281
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

I haven't studied all of the syntax details, but couldn't using a 
different unit name, such as "newbytes" (even if it's the same unit as 
bytes) be made to work? That would avoid the need to deploy a totally 
new mechanism.

Regards,   Martin.

On 2015/04/07 14:24, Mark Nottingham wrote:
> Hi Roger,
>
> There are a bunch of folks talking about how to do streaming (especially video) over HTTP, and byte ranges often come up as a mechanism. This reminds me of a discussion we briefly had at the end of the Dallas meeting, where some folks wanted to use byte ranges for sparse content in MPEG DASH.
>
> I think the concerns I had there apply here too; by overloading/changing the partial content mechanism, you’re risking interoperability problems with deployed infrastructure — especially proxy/caches, which can and do cache partial responses, generate partial requests, etc.
>
> For example, if there’s a caching proxy in the middle that doesn’t understand Accept-Indefinite-Ranges, it’ll pass it through unmodified, and the server will then potentially generate 206 responses that are malformed.
>
> This and many similar discussions I’ve had recently makes me wonder whether it’d be interesting to define a genuinely new partial content mechanism that’s tailored for media streaming; while it would depend on intermediaries rolling out support for the new mechanism to get any benefit from them, at least we could design it so that it doesn’t interact badly with deployed intermediaries.
>
> What do people (especially intermediary implementers) think?
>
> Cheers,
>
>
>
>> On 6 Apr 2015, at 10:17 pm, Rodger Combs <rodger@plexapp.com> wrote:
>>
>> Hello!
>>
>> I've written up a draft standard for an HTTP extension that allows range requests to work more effectively with resources of indeterminate length. I've submitted it as an Internet-Draft, and wondered if anyone had any suggestions as to how to improve it, or move it towards standardization?
>> https://tools.ietf.org/html/draft-combs-http-indeterminate-range-01
>>
>> Thanks,
>> --Rodger
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
> .
>

v2.23.0 | Report a Bug | By Email