[lemonade] IMAP resume

<Zoltan.Ordogh@nokia.com> Thu, 03 April 2008 11:02 UTC

Return-Path: <lemonade-bounces@ietf.org>
X-Original-To: lemonade-archive@optimus.ietf.org
Delivered-To: ietfarch-lemonade-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A94A3A6C9A; Thu, 3 Apr 2008 04:02:41 -0700 (PDT)
X-Original-To: lemonade@core3.amsl.com
Delivered-To: lemonade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C45728C0DB for <lemonade@core3.amsl.com>; Thu, 3 Apr 2008 04:02:40 -0700 (PDT)
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 T1m5mpyYv7qZ for <lemonade@core3.amsl.com>; Thu, 3 Apr 2008 04:02:34 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id ED5E43A6A2F for <lemonade@ietf.org>; Thu, 3 Apr 2008 04:02:33 -0700 (PDT)
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m33B2LFH029231 for <lemonade@ietf.org>; Thu, 3 Apr 2008 14:02:30 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 14:02:22 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 14:02:22 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 03 Apr 2008 14:02:50 +0300
Message-ID: <D11B1A8C0C8D64419879CA3C931F95E501181DD0@esebe199.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [lemonade] IMAP resume
thread-index: AciVekHjtyB+VRNUTxaR6mVFzfcSLQ==
From: Zoltan.Ordogh@nokia.com
To: lemonade@ietf.org
X-OriginalArrivalTime: 03 Apr 2008 11:02:22.0315 (UTC) FILETIME=[312583B0:01C8957A]
X-Nokia-AV: Clean
Subject: [lemonade] IMAP resume
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0540568910=="
Sender: lemonade-bounces@ietf.org
Errors-To: lemonade-bounces@ietf.org

Hi all,
here is a use case:

You're up in Norway [1], and looking at the "Children of the Earth" monument [2] at the visitor's centre in Nordkapp [3]. Your friends start making fun, so you pull out your camera and you start rolling. At some point you have a recording on your mobile phone's camera. You want to send it to your friends, so you start writing an email. While you are doing this, your friends jump in the car, ready to leave. So, you are left with a draft, which you decide to keep. You jump in the car and move on towards Hammerfest. While You are on the road, the phone will start uploading the draft to the email server. Since You are going through tunnels quite often, your upload will be interrupted every now and then, and since IMAP cannot resume a broken upload, the phone has to re-start uploading from the beginning.

The use case is not specific to Norway, Nordkapp, or the tunnels - it is merely an example. Connectivity issues can occur anywhere, any time.

The problem: a lot of resources (processing power->battery power, air interface bandwidth->the customer's/operators money and time) are wasted as the connection to the server is lost and the client attempts uploading a large content over and over again.
I know that a client should stop after a while (like three retries or something like that and try again later at some point in the future), however if there was a way resume an "upload", it would not have to, becasue the bandwidth would never be wasted.

The situation today:
SMTP does have a CHECKPOINT extension [RFC1845] that allows a broken download to be finished.
In IMAP, the best one can do currently is to slice the content to pieces, upload the pieces, and have CATENATE [RFC4469] reassemble the final piece. This is very resource-consuming on the client.

I was wondering what is the group's opinion about these things:
 - is it worth solving (I think so: a megabyte saved is a megabyte saved)
 - I am not proposing that this should be part of Profile-bis, but if it is worth solving, could it be done in the Lemonade WG? 

Any feedback on these issues is appreciated. Thank You.

References:
[1] http://en.wikipedia.org/wiki/Norway
[2] http://cache.virtualtourist.com/2899504-Children_of_the_Earth-Nordkapp.jpg
[3] http://en.wikipedia.org/wiki/Nordkapp
[RFC1845] http://tools.ietf.org/html/rfc1845
[RFC4469] http://tools.ietf.org/html/rfc4469

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade