From lemonade-bounces@ietf.org Fri Jun 01 10:34:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8Cd-0005kQ-Jg; Fri, 01 Jun 2007 10:34:07 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hu8Cc-0005kK-KK for lemonade-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 10:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8Cc-0005kC-Ai for lemonade@ietf.org; Fri, 01 Jun 2007 10:34:06 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu8CZ-0006Bp-S1 for lemonade@ietf.org; Fri, 01 Jun 2007 10:34:06 -0400 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l51EY2Pg010693 for ; Fri, 1 Jun 2007 14:34:02 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIY00801O3D0Q00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Fri, 01 Jun 2007 08:34:02 -0600 (MDT) Received: from [192.168.2.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIY009K2OGMAP10@mail-amer.sun.com> for lemonade@ietf.org; Fri, 01 Jun 2007 08:34:00 -0600 (MDT) Date: Fri, 01 Jun 2007 07:33:58 -0700 From: Chris Newman To: Lemonade WG Message-id: <3D37A496337D09B76494285A@[10.0.1.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [lemonade] RFC 4865 on SMTP Submission Service Extension for Future Message Release (fwd) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Congratulations to Greg and Greg on getting this done. Although this wasn't a Lemonade WG item, I know it's good news for the WG to see a Lemonade-related RFC published. - Chris ---------- Forwarded Message ---------- Date: Thursday, May 31, 2007 5:40 PM -0700 From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org Subject: RFC 4865 on SMTP Submission Service Extension for Future Message Release A new Request for Comments is now available in online RFC libraries. RFC 4865 Title: SMTP Submission Service Extension for Future Message Release Author: G. White, G. Vaudreuil Status: Standards Track Date: May 2007 Mailbox: g.a.white@comcast.net, GregV@ieee.org Pages: 11 Characters: 21495 Updates: RFC3463, RFC3464 See-Also: I-D Tag: draft-vaudreuil-futuredelivery-04.txt URL: http://www.rfc-editor.org/rfc/rfc4865.txt This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ---------- End Forwarded Message ---------- _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 04 15:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIZP-0003Kn-Lj; Mon, 04 Jun 2007 15:50:27 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HvIZ2-00037C-3d for lemonade-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIZ1-00036e-JL; Mon, 04 Jun 2007 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIZ0-0002oD-Ax; Mon, 04 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4C80E328F6; Mon, 4 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HvIZ0-0002hW-6f; Mon, 04 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 04 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-search-within-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : WITHIN Search extension to the IMAP Protocol Author(s) : S. Maes Filename : draft-ietf-lemonade-search-within-05.txt Pages : 5 Date : 2007-6-4 This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-search-within-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-search-within-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-4123859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-search-within-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-search-within-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-4123859.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 07 05:31:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEKc-0001YJ-Jz; Thu, 07 Jun 2007 05:31:02 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HwEKb-0001XR-Cv for lemonade-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 05:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwEKb-0001XG-0W for lemonade@ietf.org; Thu, 07 Jun 2007 05:31:01 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwEKZ-0008Qe-Mo for lemonade@ietf.org; Thu, 07 Jun 2007 05:31:00 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jun 2007 10:30:56 +0100 Message-ID: <4667D000.6090601@isode.com> Date: Thu, 07 Jun 2007 10:29:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: lemonade@ietf.org References: <46532FD0.5020903@isode.com> <46533081.80906@isode.com> In-Reply-To: <46533081.80906@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [lemonade] Re: Another WGLC on draft-ietf-lemonade-convert-08.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Alexey Melnikov wrote: > Alexey Melnikov wrote: > >> Internet-Drafts@ietf.org wrote: >> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-08.txt >> > Due to the number of changes to the document, I would like to start > another 2 weeks Working Group Last Call. > Please send your comments to me and/or to the mailing list before June > 6th. The WGLC has ended yesterday. As there were no comments received I will assume that everybody is happy with the document and will request its publication. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 11 09:41:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxk9O-0001lo-RT; Mon, 11 Jun 2007 09:41:42 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hxk9N-0001hb-4H for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 09:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxk9M-0001hT-Qx for lemonade@ietf.org; Mon, 11 Jun 2007 09:41:40 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxk9L-0004TI-DH for lemonade@ietf.org; Mon, 11 Jun 2007 09:41:40 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5BDfZCp012397 for ; Mon, 11 Jun 2007 06:41:35 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5BDfOAM011219 for ; Mon, 11 Jun 2007 06:41:25 -0700 Received: from 172.24.28.158 ([172.24.28.158]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Jun 2007 13:41:33 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 11 Jun 2007 09:41:32 -0400 From: Eric Burger To: Message-ID: Thread-Topic: Just say "Yes" Thread-Index: AcesLjiEdtFyGRghEdyLDQAWy4mm/w== In-Reply-To: <4667D000.6090601@isode.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [lemonade] Just say "Yes" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hello, anybody home? It is OK to send a, "I read the draft, and it looks good" message. For that matter, it is OK to send a, "I looked at the draft, I don't really care, but the draft will not harm the Internet" message. Capiche? On 6/7/07 2:29 AM, "Alexey Melnikov" wrote: > Alexey Melnikov wrote: > >> Alexey Melnikov wrote: >> >>> Internet-Drafts@ietf.org wrote: >>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-08.txt >>> >> Due to the number of changes to the document, I would like to start >> another 2 weeks Working Group Last Call. >> Please send your comments to me and/or to the mailing list before June >> 6th. > > The WGLC has ended yesterday. As there were no comments received I will > assume that everybody is happy with the document and will request its > publication. > > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 11 10:56:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxlJH-0003iP-Rw; Mon, 11 Jun 2007 10:55:59 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HxlJG-0003Wg-QP for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 10:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxlJG-0003SN-Ch for lemonade@ietf.org; Mon, 11 Jun 2007 10:55:58 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxlJE-0003bQ-U2 for lemonade@ietf.org; Mon, 11 Jun 2007 10:55:58 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5BEtt1H027265; Mon, 11 Jun 2007 09:55:55 -0500 (CDT) Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:55:42 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:55:42 -0500 Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:55:41 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [lemonade] Just say "Yes" Date: Mon, 11 Jun 2007 09:53:38 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19D55EB2@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Just say "Yes" Thread-Index: AcesLjiEdtFyGRghEdyLDQAWy4mm/wACMmng From: "Vaudreuil, Greg M \(Greg\)" To: "Eric Burger" , X-OriginalArrivalTime: 11 Jun 2007 14:55:41.0651 (UTC) FILETIME=[94B6EA30:01C7AC38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I read, but did not study the document. Only two items caught my attention. - How does a client know if the server will convert non-leaf body parts? It looks like a client gets to play "go fish". - Convert.size is expensive, but I'm not sure a caution to clients addresses the issue of over-use. If one uses it to improve the UI experience, it seems it would be over-use on the server. I'd prefer if we could allow convert.size to be a statistical estimate such that a server can provide low-cost estimates without actually converting the material. I can imagine a client wishing to offer "small, medium, large" buttons (with an estimated download time) next to each attachment and letting the end-user check. Rather than say this us too expensive, can we support it with estimates? Greg V. -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Monday, June 11, 2007 9:42 AM To: lemonade@ietf.org Subject: [lemonade] Just say "Yes" Hello, anybody home? It is OK to send a, "I read the draft, and it looks good" message. For that matter, it is OK to send a, "I looked at the draft, I don't really care, but the draft will not harm the Internet" message. Capiche? On 6/7/07 2:29 AM, "Alexey Melnikov" wrote: > Alexey Melnikov wrote: >=20 >> Alexey Melnikov wrote: >>=20 >>> Internet-Drafts@ietf.org wrote: >>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-08.txt >>>=20 >> Due to the number of changes to the document, I would like to start >> another 2 weeks Working Group Last Call. >> Please send your comments to me and/or to the mailing list before June >> 6th. >=20 > The WGLC has ended yesterday. As there were no comments received I will > assume that everybody is happy with the document and will request its > publication. >=20 >=20 >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 11 12:17:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxma8-000211-RH; Mon, 11 Jun 2007 12:17:28 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hxma7-00020v-U1 for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 12:17:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxma7-00020n-Kc for lemonade@ietf.org; Mon, 11 Jun 2007 12:17:27 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxma6-0002Js-8G for lemonade@ietf.org; Mon, 11 Jun 2007 12:17:27 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 11 Jun 2007 17:17:21 +0100 Message-ID: <466D753F.5040301@isode.com> Date: Mon, 11 Jun 2007 17:15:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Vaudreuil, Greg M" Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D55EB2@ILEXC2U01.ndc.lucent.com> In-Reply-To: <89017B166CB7E140BA80577FF744AE19D55EB2@ILEXC2U01.ndc.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Greg, Thank you for the feedback. Vaudreuil, Greg M (Greg) wrote: >I read, but did not study the document. Only two items caught my >attention. > >- How does a client know if the server will convert non-leaf body parts? >It looks like a client gets to play "go fish". > > The client can check if conversion from multipart/* is advertised by the server. >- Convert.size is expensive, but I'm not sure a caution to clients >addresses the issue of over-use. If one uses it to improve the UI >experience, it seems it would be over-use on the server. > >I'd prefer if we could allow convert.size to be a statistical estimate >such that a server can provide low-cost estimates without actually >converting the material. I can imagine a client wishing to offer >"small, medium, large" buttons (with an estimated download time) next to >each attachment and letting the end-user check. Rather than say this us >too expensive, can we support it with estimates? > > I think so. The estimated size should be no smaller than the actual converted size. Can you suggest some specific text that you would like to be changed or added? Thanks, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 11 14:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxoIm-0005E6-1G; Mon, 11 Jun 2007 14:07:40 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HxoIk-0005Dz-J3 for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 14:07:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxoIk-0005Dq-9V for lemonade@ietf.org; Mon, 11 Jun 2007 14:07:38 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxoIh-0003Lf-Rw for lemonade@ietf.org; Mon, 11 Jun 2007 14:07:38 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5BI7Oi0028585; Mon, 11 Jun 2007 13:07:35 -0500 (CDT) Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:07:29 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:07:29 -0500 Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:07:29 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [lemonade] Just say "Yes" Date: Mon, 11 Jun 2007 13:06:39 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> In-Reply-To: <466D753F.5040301@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Just say "Yes" Thread-Index: AcesRBdZqqkUEjQVQXKI2+SnS8cVGwADY/WQ From: "Vaudreuil, Greg M \(Greg\)" To: "Alexey Melnikov" X-OriginalArrivalTime: 11 Jun 2007 18:07:29.0216 (UTC) FILETIME=[5FC1FC00:01C7AC53] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I don't think we can specify that the error must be only in the positive direction without reducing the utility. Errors in the overstating or understating are both ungood, but I can think of use cases where either would be worse than the other. I suggest servers simply do their best with what they know and let client vendors know not to rely on the result for correct protocol operation. Try the following text. Normally, BODYSTRUCTURE provides an accurate size of a message body part to the client. However, when converting into an alternate format, the true size of the body part may not be know without performing the conversion and checking the result. For that reason, CONVERT.SIZE provides only an estimate of the body part size, with no assurance that the resulting conversion will be either larger or smaller by an unspecified margin. However, for ordinary contents, the range of likely values for a given variable-size encoding is sufficiently small as to have substantial utility with minimum server computation. Greg V. =20 -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: Monday, June 11, 2007 12:16 PM To: Vaudreuil, Greg M (Greg) Cc: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" Hi Greg, Thank you for the feedback. Vaudreuil, Greg M (Greg) wrote: >I read, but did not study the document. Only two items caught my >attention. > >- How does a client know if the server will convert non-leaf body parts? >It looks like a client gets to play "go fish". > =20 > The client can check if conversion from multipart/* is advertised by the server. >- Convert.size is expensive, but I'm not sure a caution to clients >addresses the issue of over-use. If one uses it to improve the UI >experience, it seems it would be over-use on the server. > >I'd prefer if we could allow convert.size to be a statistical estimate >such that a server can provide low-cost estimates without actually >converting the material. I can imagine a client wishing to offer >"small, medium, large" buttons (with an estimated download time) next to >each attachment and letting the end-user check. Rather than say this us >too expensive, can we support it with estimates? > =20 > I think so. The estimated size should be no smaller than the actual=20 converted size. Can you suggest some specific text that you would like to be changed or=20 added? Thanks, Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 11 14:27:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxocP-0006qD-K4; Mon, 11 Jun 2007 14:27:57 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HxocP-0006q8-31 for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 14:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxocO-0006q0-Pj for lemonade@ietf.org; Mon, 11 Jun 2007 14:27:56 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxocN-0000Wx-FG for lemonade@ietf.org; Mon, 11 Jun 2007 14:27:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5BIRSei018278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jun 2007 11:27:29 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5BIRQ5S029444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Jun 2007 11:27:28 -0700 Date: Mon, 11 Jun 2007 11:26:51 -0700 (Pacific Daylight Time) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Just say "Yes" In-Reply-To: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.co m> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.11.110855 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In my opinion, if CONVERT.SIZE does not provide the exact value (the way that BODYSTRUCTURE and BINARY.SIZE does), then it is useless and (more importantly) evil. I am amazed that Greg and Alexey would even suggest something like this that spits in the face of IMAP's architecture. Note as well that the absence of a guarantee of exact sizes forever dooms the CONVERT functionality to be unusable with partial fetching. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 11 14:45:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxotX-0001Cr-9Z; Mon, 11 Jun 2007 14:45:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HxotW-0001Cc-3U for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 14:45:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxotV-0001CU-QD for lemonade@ietf.org; Mon, 11 Jun 2007 14:45:37 -0400 Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxotU-0003tG-0b for lemonade@ietf.org; Mon, 11 Jun 2007 14:45:37 -0400 Received: from [10.201.0.49] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l5BIm3jt003781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 11:48:07 -0700 X-DKIM: Sendmail DKIM Filter v1.0.0 foon.sendmail.com l5BIm3jt003781 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1181587691; bh=DsO57FZGwgIFGS0LLTiShQglqlufoYbk3povDS aCIA8=; h=X-DomainKeys:DomainKey-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:MIME-Version: Content-Type; b=EptuRKy44pRD+DolHIt73WRPvR4z4WmoeQpCUXxZFhsjwWR2KZ Hw4FjxYpS+w+HxB2pC+VXrr3SRx2LuXCQqczWCOPBY2FHpN2RLjOTXrfs8v9wZeDTuW AZLab+Hlylh4rjcPE5IlF2zv+C2FRP0g4+GD0WUy2sYLAvqQUykhok= X-DomainKeys: Sendmail DomainKeys Filter v0.6.0 foon.sendmail.com l5BIm3jt003781 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=tirLrBXy8ybNIt6bM9Mt1x3ziuRMH6Y3lL0pImLl41YBHjCtByfExja+GeIskjxp+ 6UeWLv3zzWyxubFOkbWevM2xlSjGiMyIWdQIwEuRUPgDMZoqM6iaEMdXWgmlyLzKAID zGx4Bq3Qq6VhZUzCofaTrGdWg9F5duQGu7uvZeU= Date: Mon, 11 Jun 2007 12:45:14 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Just say "Yes" In-Reply-To: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Mon, 11 Jun 2007, Vaudreuil, Greg M (Greg) wrote: > I don't think we can specify that the error must be only in the positive > direction without reducing the utility. Errors in the overstating or > understating are both ungood, but I can think of use cases where either > would be worse than the other. I suggest servers simply do their best > with what they know and let client vendors know not to rely on the > result for correct protocol operation. That sounds reasonable to me, but I think then the fetch item should then be renamed to CONVERT.ESIZE or CONVERT.SWAG or something instead of CONVERT.SIZE to make it clear that it's different from RFC822.SIZE and BINARY.SIZE. If it's later determined that exact size info *is* worth the cost, then CONVERT.SIZE can be used for that. Document nit: this snippet in section 5: BINARY.SIZE[section-part.CONVERT ("media type/subtype" (parameters))] should read: BINARY.SIZE[section-part.CONVERT ("media type/subtype" (parameters))] as BINARY.SIZE does not permit a partial specifier Speaking of partials, I suggesting adding text similar to that in BINARY that notes that partials operate on the decoded data and not the source. Hmm, conversion data is currently in the syntax 'under' msg-att-static, which implies that the result of a particular conversion for a particular section of a given message is immutable. That's good and bad. It's good because it means a conversion can be fetched in chunks via partials. It's bad because it means a server can't upgrade converters without unreasonable bookkeeping. I have no opinion whether conversion data should be considered immutable, but the fact should be called out in prose and not just an implication of the grammar. Philip Guenther _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 11 15:51:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxpup-0003rp-KW; Mon, 11 Jun 2007 15:51:03 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1Hxpts-00016a-VW for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxptr-00014v-RJ; Mon, 11 Jun 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxptr-0007WA-F7; Mon, 11 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0230426E82; Mon, 11 Jun 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00057x-Qn; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-05.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP4 Extensions for Quick Mailbox Resynchronization Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-reconnect-client-05.txt Pages : 26 Date : 2007-6-11 This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation for a list of expunged messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-reconnect-client-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11125425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-reconnect-client-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-reconnect-client-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11125425.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon Jun 11 15:51:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpvF-0004sX-Tv; Mon, 11 Jun 2007 15:51:29 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HxpuQ-0002sy-8L for lemonade-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 15:50:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxpuM-0002mG-0V; Mon, 11 Jun 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HxpuL-0007rU-Js; Mon, 11 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D8B5F175F3; Mon, 11 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hxptq-00057W-Ju; Mon, 11 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : IMAP CONVERT extension Author(s) : S. Maes, et al. Filename : draft-ietf-lemonade-convert-09.txt Pages : 0 Date : 2007-6-11 CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-convert-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-convert-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-11123945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-convert-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-convert-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-11123945.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 14 12:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrmJ-0006O2-0C; Thu, 14 Jun 2007 12:02:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HyrmI-0006Nt-1R for lemonade-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 12:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrmH-0006Nl-OF; Thu, 14 Jun 2007 12:02:29 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyrmG-0005J9-Hp; Thu, 14 Jun 2007 12:02:29 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8174B3292C; Thu, 14 Jun 2007 16:02:28 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyrmG-0007eH-Dx; Thu, 14 Jun 2007 12:02:28 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 14 Jun 2007 12:02:28 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lemonade@ietf.org Subject: [lemonade] Last Call: draft-ietf-lemonade-rfc2192bis (IMAP URL Scheme) to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The IESG has received a request from the Enhancements to Internet email to Support Diverse Service Environments WG (lemonade) to consider the following document: - 'IMAP URL Scheme ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13735&rfc_flag=0 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Jun 17 12:12:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzxMl-0007tF-Ut; Sun, 17 Jun 2007 12:12:39 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1HzxMk-0007sg-DF for lemonade-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 12:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzxMk-0007sS-3H for lemonade@ietf.org; Sun, 17 Jun 2007 12:12:38 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzxMi-0004bg-7v for lemonade@ietf.org; Sun, 17 Jun 2007 12:12:38 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5HGCYd6018267 for ; Sun, 17 Jun 2007 09:12:34 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5HGCCsQ029251 for ; Sun, 17 Jun 2007 09:12:20 -0700 Received: from 172.24.28.132 ([172.24.28.132]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 17 Jun 2007 16:12:31 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 09:34:55 -0500 From: Eric Burger To: Message-ID: Thread-Topic: QRESYNC and UIDPLUS Thread-Index: Acew7Kwh6ulgIBzfEdy0uwAWy4mm/w== In-Reply-To: <4654196C.5000606@isode.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] QRESYNC and UIDPLUS X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In case you missed it, Alexey was asking in the thread, "concerns with draft-ietf-lemonade-reconnect-client-04.txt": On 5/23/07 6:37 PM, "Alexey Melnikov" wrote: [snip] > Having said that I would like to poll the WG regarding making QRESYNC > require UIDPLUS. Thoughts? Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 18 02:37:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Arm-0004O7-4I; Mon, 18 Jun 2007 02:37:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I0ArK-0003Op-1R for lemonade-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArH-0003Iv-Nh for lemonade@ietf.org; Mon, 18 Jun 2007 02:37:03 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ArG-0007Xf-99 for lemonade@ietf.org; Mon, 18 Jun 2007 02:37:03 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6b0ZL011667 for ; Sun, 17 Jun 2007 23:37:00 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6aUnA017603 for ; Sun, 17 Jun 2007 23:36:46 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:58 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 18 Jun 2007 13:23:23 +0900 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: WGLC reconnect-client Thread-Index: AcexYGhopt6vTB1TEdysbAAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [lemonade] WGLC reconnect-client X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org We have had a three-month rewrite of reconnect-client, and we got a new draft last week. This is an abbreviated Work Group Last Call, since the document has already had more than its two weeks' comment period. Work Group Last Call ends 25 June 2007. As usual, if the document is just fine, a brief note saying such would be appreciated. http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client-05. txt Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 18 03:24:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ban-0005ny-A3; Mon, 18 Jun 2007 03:24:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I0Baf-0005m5-QV for lemonade-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 03:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Bae-0005ko-VH for lemonade@ietf.org; Mon, 18 Jun 2007 03:23:56 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0BYj-0000u1-2O for lemonade@ietf.org; Mon, 18 Jun 2007 03:21:57 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I7LtoS022527 for ; Mon, 18 Jun 2007 00:21:55 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I7LsgA002954 for ; Mon, 18 Jun 2007 00:21:54 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 07:21:53 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 18 Jun 2007 16:21:52 +0900 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Nomcom Request Thread-Index: AcexeVd4lbxgch1sEdysbAAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.5 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [lemonade] Nomcom Request X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Forwarded on behalf of Lakshminath: From: Lakshminath Dondeti To: IETF Announcement Date: June 4, 2007 Subject: Nomcom 2007-8: First Call for Volunteers Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 18 05:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dce-00009t-IU; Mon, 18 Jun 2007 05:34:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I0Dcd-00009k-CW for lemonade-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dcc-00009b-Qu for lemonade@ietf.org; Mon, 18 Jun 2007 05:34:06 -0400 Received: from [2001:838:378:0:2a0:d2ff:fe1b:110f] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Dca-0001Rs-TL for lemonade@ietf.org; Mon, 18 Jun 2007 05:34:06 -0400 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 18 Jun 2007 10:34:01 +0100 Subject: Re: [lemonade] QRESYNC and UIDPLUS References: In-Reply-To: MIME-Version: 1.0 Message-Id: <26167.1182159220.281895@peirce.dave.cridland.net> Date: Mon, 18 Jun 2007 10:33:40 +0100 From: Dave Cridland To: Eric Burger Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun Jun 17 15:34:55 2007, Eric Burger wrote: > On 5/23/07 6:37 PM, "Alexey Melnikov" > wrote: > [snip] > Having said that I would like to poll the WG regarding > making QRESYNC > > require UIDPLUS. > > > Thoughts? Thoughts as a contributor rather than editor: I don't see the need to mandate UIDPLUS in QRESYNC. There is no technical dependency - the only time QRESYNC mentions UIDPLUS is in talking about changing the UID EXPUNGE command to emit a VANISHED response instead of EXPUNGE responses. UID EXPUNGE is not required by QRESYNC, it's merely included as an interaction issue, not a dependency. UIDPLUS, of course, remains a Good Idea to implement, and I'd be frankly astonished if a QRESYNC implementation didn't support UIDPLUS, but the protocol described in QRESYNC does not depend on it, it merely changes it in a very minor way if present. Mandating an artificial dependency because it's a Good Idea is something that Profile can, and does, do. Consider other extensions - URLAUTH is painful, if not outright useless, without UIDPLUS, yet we do not require it there - instead, we mandate it in the Profile - it's a much stronger case than QRESYNC/UIDPLUS. Similarly, draft-cridland-imap-context does not mandate ESEARCH, although an implemention of CONTEXT without ESEARCH [and, soon, ESORT] would be tricky for a client to handle. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 09:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zr4-00087G-Vp; Wed, 20 Jun 2007 09:04:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I0zr3-00087B-4F for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 09:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zr2-00086q-QN for lemonade@ietf.org; Wed, 20 Jun 2007 09:04:12 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0zqy-00017Q-Sj for lemonade@ietf.org; Wed, 20 Jun 2007 09:04:12 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Jun 2007 14:03:56 +0100 Message-ID: <46792567.5000909@isode.com> Date: Wed, 20 Jun 2007 14:02:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.co m> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Vaudreuil, Greg M \(Greg\)" , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > In my opinion, if CONVERT.SIZE does not provide the exact value (the > way that BODYSTRUCTURE and BINARY.SIZE does), then it is useless and > (more importantly) evil. > > I am amazed that Greg and Alexey would even suggest something like > this that spits in the face of IMAP's architecture. Mark, I think CONVERT is slightly different. We don't want to mandate that any conversion should be immutable forever (even though I think it should be immutable for at least the duration of the session). For example if the transcoding server is upgraded or replaced, the exact size after a particular conversion might change. Should I add some text stating this? Or do you still prefer that converted bodyparts be immutable forever? > Note as well that the absence of a guarantee of exact sizes forever > dooms the CONVERT functionality to be unusable with partial fetching. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 09:11:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zxq-0006eK-UV; Wed, 20 Jun 2007 09:11:14 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I0zxp-0006eC-Lq for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 09:11:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zxp-0006e4-BT for lemonade@ietf.org; Wed, 20 Jun 2007 09:11:13 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0zxn-0003N4-RT for lemonade@ietf.org; Wed, 20 Jun 2007 09:11:13 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Jun 2007 14:11:02 +0100 Message-ID: <46792711.4000200@isode.com> Date: Wed, 20 Jun 2007 14:09:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Vaudreuil, Greg M \(Greg\)" Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> In-Reply-To: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) wrote: >I don't think we can specify that the error must be only in the positive >direction without reducing the utility. Errors in the overstating or >understating are both ungood, but I can think of use cases where either >would be worse than the other. I suggest servers simply do their best >with what they know and let client vendors know not to rely on the >result for correct protocol operation. > >Try the following text. > >Normally, BODYSTRUCTURE provides an accurate size of a message body part >to the client. However, when converting into an alternate format, the >true size of the body part may not be know without performing the >conversion and checking the result. For that reason, CONVERT.SIZE >provides only an estimate of the body part size, with no assurance that >the resulting conversion will be either larger or smaller by an >unspecified margin. > Returning size which is bigger than the exact size is always better, as it would work with partial FETCH. A Partial range beyond the end of a converted bodypart returns no data. If the server returns size which is smaller, then the client may end up getting truncated data back. > However, for ordinary contents, the range of likely >values for a given variable-size encoding is sufficiently small as to >have substantial utility with minimum server computation. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 09:19:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I105P-0000Bu-8Y; Wed, 20 Jun 2007 09:19:03 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I105N-0000Bo-Pd for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 09:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I105N-0000Bg-G8 for lemonade@ietf.org; Wed, 20 Jun 2007 09:19:01 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I105M-0006Bi-Tq for lemonade@ietf.org; Wed, 20 Jun 2007 09:19:01 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Jun 2007 14:18:59 +0100 Message-ID: <467928EE.7000603@isode.com> Date: Wed, 20 Jun 2007 14:17:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Philip Guenther Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Vaudreuil, Greg M \(Greg\)" , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Philip Guenther wrote: > On Mon, 11 Jun 2007, Vaudreuil, Greg M (Greg) wrote: > >> I don't think we can specify that the error must be only in the positive >> direction without reducing the utility. Errors in the overstating or >> understating are both ungood, but I can think of use cases where either >> would be worse than the other. I suggest servers simply do their best >> with what they know and let client vendors know not to rely on the >> result for correct protocol operation. > > That sounds reasonable to me, but I think then the fetch item should > then be renamed to CONVERT.ESIZE or CONVERT.SWAG or something instead > of CONVERT.SIZE to make it clear that it's different from RFC822.SIZE > and BINARY.SIZE. If it's later determined that exact size info *is* > worth the cost, then CONVERT.SIZE can be used for that. I think we need to decide if CONVERT.SIZE can be unexact or not. I don't think we should have 2 versions (an exact and a "guess"), as clients are unlikely to use the "guess" version. > Document nit: this snippet in section 5: > BINARY.SIZE[section-part.CONVERT ("media type/subtype" > (parameters))] > > should read: > > BINARY.SIZE[section-part.CONVERT ("media type/subtype" > (parameters))] > > as BINARY.SIZE does not permit a partial specifier Good catch. Fixed. > Speaking of partials, I suggesting adding text similar to that in > BINARY that notes that partials operate on the decoded data and not > the source. Done. > Hmm, conversion data is currently in the syntax 'under' > msg-att-static, which implies that the result of a particular > conversion for a particular section of a given message is immutable. > That's good and bad. It's good because it means a conversion can be > fetched in chunks via partials. It's bad because it means a server > can't upgrade converters without unreasonable bookkeeping. I agree that this needs to be clarified. See also my reply to Mark. > I have no opinion whether conversion data should be considered > immutable, but the fact should be called out in prose and not just an > implication of the grammar. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 09:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10Zg-0006ZY-B8; Wed, 20 Jun 2007 09:50:20 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I10Zf-0006ZN-Gi for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 09:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10Zf-0006ZF-7D for lemonade@ietf.org; Wed, 20 Jun 2007 09:50:19 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10Zb-0005LG-SC for lemonade@ietf.org; Wed, 20 Jun 2007 09:50:19 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5KDnDgv029325; Wed, 20 Jun 2007 08:50:12 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 08:49:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Just say "Yes" Date: Wed, 20 Jun 2007 08:49:13 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19DF27E2@ILEXC2U01.ndc.lucent.com> In-Reply-To: <46792711.4000200@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Just say "Yes" Thread-Index: AcezPHujSghHnxqlSjexwYLbnygP2AAAwagA From: "Vaudreuil, Greg M \(Greg\)" To: "Alexey Melnikov" X-OriginalArrivalTime: 20 Jun 2007 13:49:14.0203 (UTC) FILETIME=[C9BA62B0:01C7B341] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I assert that an estimate is the only affordable value available to a server: Further, I believe this estimate can't be relied upon to be larger than the true size of the converted content. The only way to return a value that is larger than the exact size is to either: 1) Compute the exact size (why then bother with the estimate?)=20 2) Always give a best-case (smallest) estimate, which could be very far off since most compressions *can* result in tiny files (imagine a minute of mostly silence compressed, or a picture that is mostly black background) So, I think we need to figure out how to make this protocol work with an estimate, modifying what fetch partial returns when it tries to read past the end of data. Greg V. -----Original Message----- From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] Sent: Wednesday, June 20, 2007 9:10 AM To: Vaudreuil, Greg M (Greg) Cc: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" Vaudreuil, Greg M (Greg) wrote: >I don't think we can specify that the error must be only in the positive >direction without reducing the utility. Errors in the overstating or >understating are both ungood, but I can think of use cases where either >would be worse than the other. I suggest servers simply do their best >with what they know and let client vendors know not to rely on the >result for correct protocol operation. > >Try the following text. > >Normally, BODYSTRUCTURE provides an accurate size of a message body part >to the client. However, when converting into an alternate format, the >true size of the body part may not be know without performing the >conversion and checking the result. For that reason, CONVERT.SIZE >provides only an estimate of the body part size, with no assurance that >the resulting conversion will be either larger or smaller by an >unspecified margin. > Returning size which is bigger than the exact size is always better, as=20 it would work with partial FETCH. A Partial range beyond the end of a=20 converted bodypart returns no data. If the server returns size which is=20 smaller, then the client may end up getting truncated data back. > However, for ordinary contents, the range of likely >values for a given variable-size encoding is sufficiently small as to >have substantial utility with minimum server computation. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 10:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I119x-0001in-9I; Wed, 20 Jun 2007 10:27:49 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I119v-0001i4-QV for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 10:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I119v-0001hw-Gz for lemonade@ietf.org; Wed, 20 Jun 2007 10:27:47 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I119s-0002Sn-66 for lemonade@ietf.org; Wed, 20 Jun 2007 10:27:47 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Jun 2007 15:27:39 +0100 Message-ID: <46793906.6000903@isode.com> Date: Wed, 20 Jun 2007 15:26:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "Vaudreuil, Greg M \(Greg\)" Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19DF27E2@ILEXC2U01.ndc.lucent.com> In-Reply-To: <89017B166CB7E140BA80577FF744AE19DF27E2@ILEXC2U01.ndc.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) wrote: >I assert that an estimate is the only affordable value available to a >server: > >Further, I believe this estimate can't be relied upon to be larger than >the true size of the converted content. The only way to return a value >that is larger than the exact size is to either: > > 1) Compute the exact size (why then bother with the estimate?) > 2) Always give a best-case (smallest) estimate, which could be very >far off since most compressions *can* result in tiny files (imagine a >minute of mostly silence compressed, or a picture that is mostly black >background) > >So, I think we need to figure out how to make this protocol work with an >estimate, modifying what fetch partial returns when it tries to read >past the end of data. > > As I said below, reading past the end of converted data is not a problem in IMAP. Data truncation is. Data truncation can occur if the returned converted size is smaller than the actual converted size. If the client uses FETCH, it will not bother downloading the part of the converted bodypart which is between the returned and the actual size. One possible way of allowing CONVERT.SIZE to be inexact while allowing for FETCH is to force return of the correct converted size upon a CONVERT request. But this looks suboptimal to me and might lead to interoperability problems. (Think about clients cashing the wrong value or being tested against the server that always returns the correct size) >Greg V. > >-----Original Message----- >From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >Sent: Wednesday, June 20, 2007 9:10 AM >To: Vaudreuil, Greg M (Greg) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] Just say "Yes" > > >Vaudreuil, Greg M (Greg) wrote: > > >>I don't think we can specify that the error must be only in the positive >> >> >>direction without reducing the utility. Errors in the overstating or >>understating are both ungood, but I can think of use cases where either >>would be worse than the other. I suggest servers simply do their best >>with what they know and let client vendors know not to rely on the >>result for correct protocol operation. >> >>Try the following text. >> >>Normally, BODYSTRUCTURE provides an accurate size of a message body part >> >> >>to the client. However, when converting into an alternate format, the >>true size of the body part may not be know without performing the >>conversion and checking the result. For that reason, CONVERT.SIZE >>provides only an estimate of the body part size, with no assurance that >>the resulting conversion will be either larger or smaller by an >>unspecified margin. >> >> >Returning size which is bigger than the exact size is always better, as >it would work with partial FETCH. A Partial range beyond the end of a >converted bodypart returns no data. If the server returns size which is >smaller, then the client may end up getting truncated data back. > > >> However, for ordinary contents, the range of likely >>values for a given variable-size encoding is sufficiently small as to >>have substantial utility with minimum server computation. >> >> _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 11:24:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1238-0003JB-Ca; Wed, 20 Jun 2007 11:24:50 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1237-0003J6-8q for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1236-0003Iy-Vf for lemonade@ietf.org; Wed, 20 Jun 2007 11:24:48 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1234-00039O-Im for lemonade@ietf.org; Wed, 20 Jun 2007 11:24:48 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KFOhBN006747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 08:24:43 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KFOYkg011532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2007 08:24:42 -0700 Date: Wed, 20 Jun 2007 08:24:33 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <46792567.5000909@isode.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.co m> <46792567.5000909@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.80735 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Vaudreuil, Greg M \(Greg\)" , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 20 Jun 2007, Alexey Melnikov wrote: > We don't want to mandate that any conversion should be immutable forever > (even though I think it should be immutable for at least the duration of the > session). For example if the transcoding server is upgraded or replaced, the > exact size after a particular conversion might change. Immutable for the duration of the session (but not forever) is probably alright, but the authors of disconnected clients may disagree. > Or do you still prefer that converted bodyparts be immutable forever? I think that immutable forever, and control over the conversion algorithm is better. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 11:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I124y-00076o-RF; Wed, 20 Jun 2007 11:26:44 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I124x-00075b-Pj for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I124x-00075T-GJ for lemonade@ietf.org; Wed, 20 Jun 2007 11:26:43 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I124u-0003Ys-K3 for lemonade@ietf.org; Wed, 20 Jun 2007 11:26:43 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KFQZMV019760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 08:26:35 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KFQW0E000502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2007 08:26:34 -0700 Date: Wed, 20 Jun 2007 08:26:32 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <46792711.4000200@isode.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <46792711.4000200@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.80735 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "Vaudreuil, Greg M \(Greg\)" , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 20 Jun 2007, Alexey Melnikov wrote: > Returning size which is bigger than the exact size is always better, as it > would work with partial FETCH. A Partial range beyond the end of a converted > bodypart returns no data. If the server returns size which is smaller, then > the client may end up getting truncated data back. This isn't how clients that do partial fetching work; and if you look at what the protocol says on this you'll see that the situation that you describe is ambiguous. Some clients will end up looping. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 11:28:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I126i-0002xI-R1; Wed, 20 Jun 2007 11:28:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I126i-0002xD-ET for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:28:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I126i-0002x5-4y for lemonade@ietf.org; Wed, 20 Jun 2007 11:28:32 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I126f-0003xk-QP for lemonade@ietf.org; Wed, 20 Jun 2007 11:28:32 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KFSQu4013197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 08:28:27 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KFSOu3000813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2007 08:28:25 -0700 Date: Wed, 20 Jun 2007 08:28:23 -0700 (PDT) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Just say "Yes" In-Reply-To: <89017B166CB7E140BA80577FF744AE19DF27E2@ILEXC2U01.ndc.lucent.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19DF27E2@ILEXC2U01.ndc.lucent.co m> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.81355 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 20 Jun 2007, Vaudreuil, Greg M (Greg) wrote: > So, I think we need to figure out how to make this protocol work with an > estimate, modifying what fetch partial returns when it tries to read > past the end of data. It is better to return no size at all than a lie. NNTP is a great example of what happens when the protocol lies. IMAP does not have this bug. If you want to produce a "display" size, that may be OK, but then do it is something that is obviously not related to reality, such as a value in "K". -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 11:29:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I127s-0006bf-EA; Wed, 20 Jun 2007 11:29:44 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I127r-0006ba-8E for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I127q-0006bS-V3 for lemonade@ietf.org; Wed, 20 Jun 2007 11:29:42 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I127p-0004LZ-L9 for lemonade@ietf.org; Wed, 20 Jun 2007 11:29:42 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KFTdQl027388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 08:29:39 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KFTaaA013330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2007 08:29:38 -0700 Date: Wed, 20 Jun 2007 08:29:35 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <46793906.6000903@isode.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19DF27E2@ILEXC2U01.ndc.lucent.com> <46793906.6000903@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.80735 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "Vaudreuil, Greg M \(Greg\)" , Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 20 Jun 2007, Alexey Melnikov wrote: > As I said below, reading past the end of converted data is not a problem in > IMAP. As the author of client code that does partial fetching, I disagree. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 11:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Hf-0007pa-Bk; Wed, 20 Jun 2007 11:39:51 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I12Hd-0007lW-Nd for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Hd-0007lO-E6 for lemonade@ietf.org; Wed, 20 Jun 2007 11:39:49 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12Hb-0000AI-4S for lemonade@ietf.org; Wed, 20 Jun 2007 11:39:49 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Jun 2007 16:39:44 +0100 Message-ID: <467949EB.3030706@isode.com> Date: Wed, 20 Jun 2007 16:38:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19DF27E2@ILEXC2U01.ndc.lucent.com> <46793906.6000903@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "Vaudreuil, Greg M \(Greg\)" , Lemonade WG X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > On Wed, 20 Jun 2007, Alexey Melnikov wrote: > >> As I said below, reading past the end of converted data is not a >> problem in IMAP. > > As the author of client code that does partial fetching, I disagree. Ok, I can restate that: my server handles this gracefully ;-). _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 11:48:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Pc-0000YQ-OS; Wed, 20 Jun 2007 11:48:04 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I12Pa-0000YL-Sp for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12Pa-0000YD-JO for lemonade@ietf.org; Wed, 20 Jun 2007 11:48:02 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12PZ-0002U2-2Q for lemonade@ietf.org; Wed, 20 Jun 2007 11:48:02 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id l5KFX9S14784 for ; Wed, 20 Jun 2007 16:33:10 +0100 (BST) Received: from 10.0.0.9 ([10.0.0.9]) by svr-exchange.avocado.emccsoft.com ([10.0.0.9]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 Jun 2007 15:47:15 +0000 From: "Ben Last" To: Subject: Re: [lemonade] Just say "Yes" Message-ID: <009801c7b352$463f83aa$0900000a@avocado.emccsoft.com> Date: 20 Jun 2007 15:42:50 +0000 Content-Type: text/plain; charset="Utf-8" Content-Transfer-Encoding: quoted-printable Importance: Normal MIME-Version: 1.0 Thread-Topic: [lemonade] Just say "Yes" Thread-Index: AcezUkY/OEiNjQ3PSN+SZilRNdRJ5w== X-MimeOLE: Produced By Microsoft Exchange V6.5 X-Spam-Score: 3.1 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I second Mark's point: our client expects that a FETCHable part of a = message that's reported as X bytes will *be* X bytes, and does not like = empty (or absent) FETCH responses, which are generally assumed to = indicate some sort of failure. Ben . -----Original Message----- From: Mark Crispin Sent: Wed 20/06/2007 16:26 To: Alexey Melnikov Cc: Vaudreuil, Greg M \(Greg\);lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" =20 On Wed, 20 Jun 2007, Alexey Melnikov wrote: > Returning size which is bigger than the exact size is always better, = as it=20 > would work with partial FETCH. A Partial range beyond the end of a = converted=20 > bodypart returns no data. If the server returns size which is smaller, = then=20 > the client may end up getting truncated data back. This isn't how clients that do partial fetching work; and if you look at = what the protocol says on this you'll see that the situation that you=20 describe is ambiguous. Some clients will end up looping. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 11:54:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12VP-0002kN-95; Wed, 20 Jun 2007 11:54:03 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I12VN-0002gu-85 for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12VM-0002eo-Tv for lemonade@ietf.org; Wed, 20 Jun 2007 11:54:00 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12VL-0004ou-J5 for lemonade@ietf.org; Wed, 20 Jun 2007 11:54:00 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l5KFrvdM022233; Wed, 20 Jun 2007 10:53:57 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:53:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Just say "Yes" Date: Wed, 20 Jun 2007 10:52:31 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Just say "Yes" Thread-Index: AcezT6eYMarNofkoSFCsYvsC/2jpkgAAvIgg From: "Vaudreuil, Greg M \(Greg\)" To: "Mark Crispin" X-OriginalArrivalTime: 20 Jun 2007 15:53:47.0606 (UTC) FILETIME=[30392F60:01C7B353] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I'm happy with redefining this as a display size, and even making the granularity "k" to help client writers get the hint. =20 What needs to be clear is that clients should only request, or better, can only request, an accurate size as part of the converted content fetch, where the conversion is performed anyway. Greg V. -----Original Message----- From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com]On Behalf Of Mark Crispin Sent: Wednesday, June 20, 2007 11:28 AM To: Vaudreuil, Greg M (Greg) Cc: Alexey Melnikov; lemonade@ietf.org Subject: RE: [lemonade] Just say "Yes" On Wed, 20 Jun 2007, Vaudreuil, Greg M (Greg) wrote: > So, I think we need to figure out how to make this protocol work with an > estimate, modifying what fetch partial returns when it tries to read > past the end of data. It is better to return no size at all than a lie. NNTP is a great example of what happens when the protocol lies. IMAP does=20 not have this bug. If you want to produce a "display" size, that may be OK, but then do it is=20 something that is obviously not related to reality, such as a value in=20 "K". -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 12:21:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12vV-0005J3-R6; Wed, 20 Jun 2007 12:21:01 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I12vU-0005EN-MA for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:21:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12vU-0005D6-Az for lemonade@ietf.org; Wed, 20 Jun 2007 12:21:00 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12vS-0005Cf-V8 for lemonade@ietf.org; Wed, 20 Jun 2007 12:21:00 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KGKoMF014118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 09:20:50 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KGKkgm021347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2007 09:20:49 -0700 Date: Wed, 20 Jun 2007 09:20:45 -0700 (PDT) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Just say "Yes" In-Reply-To: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.co m> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.90639 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In that case, the specification MUST prohibit the use of partial fetching, stipulate that both in the text and in the formal syntax, AND explain why partial fetching is prohibited. Otherwise, this particular conversation will never end; it will come up over, and over, again. I can guarantee you that some client author is going to want to try partial fetching and will run up against the problem. If he is particularly unlucky, he will test against a server that returns exact values (although using "K" or even "M" will help avoid this) and not find out about servers which lie until later. And, at some point, someone is going to ask why this wart is in IMAP when all modern servers have no trouble with computing exact sizes and why should we care about dinosaur software/hardware. Such nightmares are the reality of NNTP, and the cretins in that group refused to fix it when they had a chance. Fortunately, netnews is dying as an Internet service (all of about 60 people at UW still use it) so it doesn't really matter any more. Presumably IMAP still has a little bit more life left in it. We ought to try to design IMAP as if it is still alive, and not just dump in any old trash just because it is convenient. I'd like to mention, as an aside, that the requirement in IMAP that message sizes be exact was a TERRIBLE blow to a certain well-known vendor who used a database as a message store and didn't have the message stored in RFC822 format at all. They thought those sizes were estimates, and found out otherwise the hard way. They ended up having to redo their message store in order to implement IMAP with any type of efficiency. So it isn't as if this is a new problem. It isn't. On Wed, 20 Jun 2007, Vaudreuil, Greg M (Greg) wrote: > I'm happy with redefining this as a display size, and even making the > granularity "k" to help client writers get the hint. > > What needs to be clear is that clients should only request, or better, > can only request, an accurate size as part of the converted content > fetch, where the conversion is performed anyway. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 12:29:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I133h-0003lH-TD; Wed, 20 Jun 2007 12:29:29 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I133g-0003l6-G1 for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I133g-0003kx-6H for lemonade@ietf.org; Wed, 20 Jun 2007 12:29:28 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I133e-0007jU-Q7 for lemonade@ietf.org; Wed, 20 Jun 2007 12:29:28 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KGTNVU030703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 09:29:24 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KGTLUg015302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2007 09:29:22 -0700 Date: Wed, 20 Jun 2007 09:29:20 -0700 (PDT) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Just say "Yes" In-Reply-To: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.co m> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.91233 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think that it is a serious design flaw that CONVERT is a FETCH data item at all. It violates the design principle that all FETCH message data in IMAP is immutable (metadata being a different matter). Instead, I recommend that CONVERT be a new command in IMAP. What is being done is an additional server operation, not merely a FETCH. Then, if you want to have partial fetching of converted data, you can create a new framework for doing so that doesn't cause the problems from IMAP's framework. Arguably, IMAP BINARY should have been a different command, as well as any IMAP Unicode fetch, since those are also "conversions". But those both return immutable data with sizes that are equally immutable, so that is a razor that can be justified. CONVERT, as I understand it, is a server-based possibly lossy conversion that is server implementation-dependent (and thus different compliant servers can convert differently). This is NOT something that should be part of the IMAP FETCH framework. Most of my objections would become moot if you make this a new command. I'm willing to help out on reforming the design to be a new command, at least to sketch out syntax. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 12:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13XD-00085P-KT; Wed, 20 Jun 2007 12:59:59 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I13XC-00084z-Sw for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13XC-00084r-JV for lemonade@ietf.org; Wed, 20 Jun 2007 12:59:58 -0400 Received: from 204-174-83-38.static569.dsl.ucc-net.ca ([204.174.83.38] helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13XB-0006qe-87 for lemonade@ietf.org; Wed, 20 Jun 2007 12:59:58 -0400 Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.1/8.14.1) with ESMTP id l5KGxL3n020402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 09:59:21 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 20 Jun 2007 09:59:21 -0700 (PDT) From: Lyndon Nerenberg To: Alexey Melnikov Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <467928EE.7000603@isode.com> Message-ID: <20070620095721.M20197@orthanc.ca> References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,NO_RELAYS autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Philip Guenther , "Vaudreuil, Greg M \(Greg\)" , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > I think we need to decide if CONVERT.SIZE can be unexact or not. > I don't think we should have 2 versions (an exact and a "guess"), as clients > are unlikely to use the "guess" version. Either it's exact, or it needs to come out. Inaccurate data is worse than useless in this instance. --lyndon Good judgement comes from experience. Unfortunately, experience comes from bad judgement. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 14:04:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14XJ-0000Yd-2H; Wed, 20 Jun 2007 14:04:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I14XH-0000YY-Ic for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 14:04:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14XH-0000YQ-8p for lemonade@ietf.org; Wed, 20 Jun 2007 14:04:07 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14XF-0003C2-Rh for lemonade@ietf.org; Wed, 20 Jun 2007 14:04:07 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 99A2E4AC5A; Wed, 20 Jun 2007 20:04:04 +0200 (CEST) Message-Id: Date: Wed, 20 Jun 2007 20:04:04 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.com> In-Reply-To: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: gregv@alcatel-lucent.com, Alexey Melnikov , Mark Crispin X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) writes: > I'm happy with redefining this as a display size, and even making the > granularity "k" to help client writers get the hint. +1 Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 14:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14jd-0007nE-Bx; Wed, 20 Jun 2007 14:16:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I14jc-0007jU-N7 for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 14:16:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14jc-0007hk-Cm for lemonade@ietf.org; Wed, 20 Jun 2007 14:16:52 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14ja-0005Z6-UD for lemonade@ietf.org; Wed, 20 Jun 2007 14:16:52 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id EF6FC4AC64; Wed, 20 Jun 2007 20:16:49 +0200 (CEST) Message-Id: Date: Wed, 20 Jun 2007 20:16:49 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> In-Reply-To: <20070620095721.M20197@orthanc.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: gregv@alcatel-lucent.com, Alexey, Lyndon Nerenberg , Philip Guenther , Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lyndon Nerenberg writes: >> I think we need to decide if CONVERT.SIZE can be unexact or not. >> I don't think we should have 2 versions (an exact and a "guess"), as >> clients are unlikely to use the "guess" version. > > Either it's exact, or it needs to come out. Inaccurate data is worse > than useless in this instance. Why? Could you elaborate your viewpoint? I see no need for exactness - returning an integer number of tenths would satisfy me. "About one tenth of the original size", "about three tenths ..." etc. This is because I only want to answer the question "how much speed will I earn by getting this approximating conversion?" and I'd rather get the options quickly than know the exact traffic savings. Obviously your thinking is very different, and I'm curious as to how. Btw, I don't agree that clients are unlikely to use the guess version. If there's language saying "the server SHOULD be quick, even at the expense of accuracy..." and/or "clients wanting an answer quickly MUST use the inexact...", I think that provides real incentive to use an inexact version. For example, when you're displaying a dialog, it's a definite advantage to have it done within about 0.2-0.7 seconds depending on type of dialog. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 14:24:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14r4-00026L-Ro; Wed, 20 Jun 2007 14:24:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I14r3-00026G-5r for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 14:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14r2-000268-SZ for lemonade@ietf.org; Wed, 20 Jun 2007 14:24:32 -0400 Received: from mumbo.ca ([65.61.206.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14r1-0008HD-Ji for lemonade@ietf.org; Wed, 20 Jun 2007 14:24:32 -0400 Received: from [192.168.1.101] (S01060012170dd046.cg.shawcable.net [68.146.210.109]) by mumbo.ca (Postfix) with ESMTP id 439278383B; Wed, 20 Jun 2007 12:24:30 -0600 (MDT) In-Reply-To: References: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.co m> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AD05E57-F8C6-420F-8F97-A4D97D32C8EE@mumbo.ca> Content-Transfer-Encoding: 7bit From: Curtis King Subject: Re: [lemonade] Just say "Yes" Date: Wed, 20 Jun 2007 12:24:26 -0600 To: Mark Crispin X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Vaudreuil, Greg M \(Greg\)" , lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Jun 20, 2007, at 10:29 AM, Mark Crispin wrote: > CONVERT, as I understand it, is a server-based possibly lossy > conversion that is server implementation-dependent (and thus > different compliant servers can convert differently). This is NOT > something that should be part of the IMAP FETCH framework. > > Most of my objections would become moot if you make this a new > command. +1 on making CONVERT a new command. ck _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 15:33:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15w1-0002zt-Pq; Wed, 20 Jun 2007 15:33:45 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I15w0-0002zf-KA for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15w0-0002zP-AV for lemonade@ietf.org; Wed, 20 Jun 2007 15:33:44 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15vy-0003Yy-SI for lemonade@ietf.org; Wed, 20 Jun 2007 15:33:44 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KJXfMU016474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 12:33:41 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washignton.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KJXfJx017539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jun 2007 12:33:41 -0700 Date: Wed, 20 Jun 2007 12:33:31 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Just say "Yes" In-Reply-To: Message-ID: References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.121732 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 20 Jun 2007, Arnt Gulbrandsen wrote: > Lyndon Nerenberg writes: >> Either it's exact, or it needs to come out. Inaccurate data is worse than >> useless in this instance. > Why? Could you elaborate your viewpoint? What purpose does this value purport to serve? In every other place in IMAP, sizes are used as exact values to allocate space and for partial fetch markers. For some reason, you guys seem to be advocating a different type of size, with no apparent purpose, yet omitting the size that software expects (and NEEDS), all with the weak excuse that "it'd be too inefficient for some servers." > I see no need for exactness - returning an integer number of tenths would > satisfy me. "About one tenth of the original size", "about three tenths ..." > etc. This is because I only want to answer the question "how much speed will > I earn by getting this approximating conversion?" and I'd rather get the > options quickly than know the exact traffic savings. Obviously your thinking > is very different, and I'm curious as to how. If this is the functionality that you seek to accomplish, then you should do it by some other mechanism than delivering a lie that will mislead clients into incorrect behavior. > Btw, I don't agree that clients are unlikely to use the guess version. If > there's language saying "the server SHOULD be quick, even at the expense of > accuracy..." and/or "clients wanting an answer quickly MUST use the > inexact...", I think that provides real incentive to use an inexact version. NNTP has this same type of thinking. NNTP sucks. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 15:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I164n-0004se-Sy; Wed, 20 Jun 2007 15:42:49 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I164l-0004sY-Vu for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I164l-0004sQ-MR for lemonade@ietf.org; Wed, 20 Jun 2007 15:42:47 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I164k-0005hL-AA for lemonade@ietf.org; Wed, 20 Jun 2007 15:42:47 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 751124AC5A for ; Wed, 20 Jun 2007 21:42:45 +0200 (CEST) Message-Id: Date: Wed, 20 Jun 2007 21:42:45 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin writes: > On Wed, 20 Jun 2007, Arnt Gulbrandsen wrote: >> Lyndon Nerenberg writes: >>> Either it's exact, or it needs to come out. Inaccurate data is >>> worse than useless in this instance. >> Why? Could you elaborate your viewpoint? > > What purpose does this value purport to serve? Selecting which approximating conversion to fetch, if any? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 15:45:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I167M-0007b8-SA; Wed, 20 Jun 2007 15:45:28 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I167L-0007X7-5n for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I167K-0007Uq-PW for lemonade@ietf.org; Wed, 20 Jun 2007 15:45:26 -0400 Received: from 204-174-83-38.static569.dsl.ucc-net.ca ([204.174.83.38] helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I167J-0006Ng-DR for lemonade@ietf.org; Wed, 20 Jun 2007 15:45:26 -0400 Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.1/8.14.1) with ESMTP id l5KJivUI021363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 12:44:57 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 20 Jun 2007 12:44:57 -0700 (PDT) From: Lyndon Nerenberg To: Arnt Gulbrandsen Subject: Re: [lemonade] Just say "Yes" In-Reply-To: Message-ID: <20070620122316.W20197@orthanc.ca> References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,NO_RELAYS autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: lemonade@ietf.org, Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Why? Could you elaborate your viewpoint? If the size is inaccurate it's because the server is guessing (to some unknown amount of accuracy) about the outcome of the transformation. In the simple case, it's going to take the size of the original and run it through a simple algorithm to derive it's guess. If a client considers an available transformation viable, it can just as easily compute this guess from the size information already at hand (and potentially saving an RTT). This makes CONVERT.SIZE superfluous. The server might use it's knowledge of the content and structure of the part to perform a partial evaluation of the part's contents to calculate a more accurate guess. It's my contention that once you start doing a partial evaluation, you're most of the way to just doing it right and calculating the exact value. But why are inexact values inherently evil? Because clients -- despite all the protests everyone cares to make to the contrary -- will treat them as exact values, and then fail when their assumptions about the data turn out to be wrong. If you haven't learned by now that client writers will take the most stupid path imaginable, multiply the brain damage by 10, and then incorrectly implement their incorrect assumptions ... well, you shouldn't be in the IMAP business. If the intent of CONVERT.SIZE is to provide a display value, any client that can make use of the converted type can calculate the approximate size of the converted object to a precision far exceeding what is necessary for display purposes (about three significant digits for any device I'm familiar with). Therefore, not only is CONVERT.SIZE unnecessary for protocol functionality, it's introduction will actively harm interoperability. Note that from a server implementation standpoint you can do lazy evaluation of CONTENT.SIZE -- just as with BINARY.SIZE -- and cache the result; providing accurate CONTENT.SIZE does not have to imply a general performance hit. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 15:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16CI-0004wb-2E; Wed, 20 Jun 2007 15:50:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I16CG-0004wD-Qt for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16CG-0004w5-HQ for lemonade@ietf.org; Wed, 20 Jun 2007 15:50:32 -0400 Received: from 204-174-83-38.static569.dsl.ucc-net.ca ([204.174.83.38] helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16CF-00079p-62 for lemonade@ietf.org; Wed, 20 Jun 2007 15:50:32 -0400 Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.1/8.14.1) with ESMTP id l5KJo41c021423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 12:50:04 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 20 Jun 2007 12:50:04 -0700 (PDT) From: Lyndon Nerenberg To: Arnt Gulbrandsen Subject: Re: [lemonade] Just say "Yes" In-Reply-To: Message-ID: <20070620124851.M20197@orthanc.ca> References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,NO_RELAYS autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >> What purpose does this value purport to serve? > Selecting which approximating conversion to fetch, if any? Oh good lord, can we just drop the 'Engineering' from IETF? This is just absurd. If this is truly the reason then drop CONVERT.SIZE and have the client randomly pick one of the conversions. --lyndon I have challenged the entire quality assurance team to a Bat-Leth contest. They will not concern us again. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 16:10:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16VV-0008Ko-8U; Wed, 20 Jun 2007 16:10:25 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I16VS-0008KY-W2 for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:10:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16VS-0008KQ-Ma for lemonade@ietf.org; Wed, 20 Jun 2007 16:10:22 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16VR-0003T0-8k for lemonade@ietf.org; Wed, 20 Jun 2007 16:10:22 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 5DC004AC5E for ; Wed, 20 Jun 2007 22:10:20 +0200 (CEST) Message-Id: Date: Wed, 20 Jun 2007 22:10:20 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> In-Reply-To: <20070620124851.M20197@orthanc.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lyndon Nerenberg writes: >>> What purpose does this value purport to serve? >> Selecting which approximating conversion to fetch, if any? > > Oh good lord, can we just drop the 'Engineering' from IETF? This is > just absurd. If this is truly the reason then drop CONVERT.SIZE and > have the client randomly pick one of the conversions. Picking randomly is an advance over presenting a dialog like this? Choose format for downloading: [ ] Exact file (est. download time 10m) [ ] Blah conversion blah a (est. download time 3m) [ ] Blah conversion blah b (est. download time 30s) > --lyndon > > I have challenged the entire quality assurance team to a Bat-Leth > contest. They will not concern us again. Strangely appropriate tag. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 16:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16hG-00035M-CU; Wed, 20 Jun 2007 16:22:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I16hF-00035G-0b for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16hE-000358-NI for lemonade@ietf.org; Wed, 20 Jun 2007 16:22:32 -0400 Received: from 204-174-83-38.static569.dsl.ucc-net.ca ([204.174.83.38] helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16hD-0006Uq-BY for lemonade@ietf.org; Wed, 20 Jun 2007 16:22:32 -0400 Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.1/8.14.1) with ESMTP id l5KKM439021679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jun 2007 13:22:04 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Wed, 20 Jun 2007 13:22:04 -0700 (PDT) From: Lyndon Nerenberg To: Arnt Gulbrandsen Subject: Re: [lemonade] Just say "Yes" In-Reply-To: Message-ID: <20070620131120.P20197@orthanc.ca> References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,NO_RELAYS autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Picking randomly is an advance over presenting a dialog like this? > > Choose format for downloading: > [ ] Exact file (est. download time 10m) > [ ] Blah conversion blah a (est. download time 3m) > [ ] Blah conversion blah b (est. download time 30s) The dialog is not the issue. The issue is that if you're going to guess, the client can guess just as well as the server. Therefore CONVERT.SIZE provides no benefit. --lyndon NT as a file server is faster than a dead bat carrying Post-It notes underwater. But not by much. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 16:35:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16tt-0005R1-CV; Wed, 20 Jun 2007 16:35:37 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I16ts-0005Qa-Eo for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 16:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16ts-0005QL-4x for lemonade@ietf.org; Wed, 20 Jun 2007 16:35:36 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16tq-0001K6-Hk for lemonade@ietf.org; Wed, 20 Jun 2007 16:35:35 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5KKZXkL008901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2007 13:35:33 -0700 X-Auth-Received: from Ningyo-no-Mori.Panda.COM (D-128-208-207-71.dhcp4.washington.edu [128.208.207.71]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5KKZX57028738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jun 2007 13:35:33 -0700 Date: Wed, 20 Jun 2007 13:35:30 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lyndon Nerenberg Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <20070620122316.W20197@orthanc.ca> Message-ID: References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620122316.W20197@orthanc.ca> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.20.132033 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 20 Jun 2007, Lyndon Nerenberg wrote: > If you haven't learned by now that client writers will take the > most stupid path imaginable, multiply the brain damage by 10, and then > incorrectly implement their incorrect assumptions ... well, you shouldn't be > in the IMAP business. +1 And not just client writers. Server writers do some amazingly bad things too. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 20 18:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1908-0007lO-PW; Wed, 20 Jun 2007 18:50:12 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1900-0007I3-7P for lemonade-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 18:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18zz-0007GC-Pz; Wed, 20 Jun 2007 18:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I18zy-0005HX-BN; Wed, 20 Jun 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 30BA7328EB; Wed, 20 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I18zy-0005hm-2x; Wed, 20 Jun 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 20 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-09.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-09.txt Pages : 14 Date : 2007-6-20 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-20153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-20153513.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Thu Jun 21 14:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1R0M-0000KN-JK; Thu, 21 Jun 2007 14:03:38 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1R0L-0000KH-4k for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1R0K-0000K9-RQ for lemonade@ietf.org; Thu, 21 Jun 2007 14:03:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1R0J-0003sE-FH for lemonade@ietf.org; Thu, 21 Jun 2007 14:03:36 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Jun 2007 19:03:32 +0100 Message-ID: <467ABD1A.8010107@isode.com> Date: Thu, 21 Jun 2007 19:02:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lyndon Nerenberg Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> <20070620131120.P20197@orthanc.ca> In-Reply-To: <20070620131120.P20197@orthanc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lyndon Nerenberg wrote: >> Picking randomly is an advance over presenting a dialog like this? >> >> Choose format for downloading: >> [ ] Exact file (est. download time 10m) >> [ ] Blah conversion blah a (est. download time 3m) >> [ ] Blah conversion blah b (est. download time 30s) > > The dialog is not the issue. The issue is that if you're going to > guess, the client can guess just as well as the server. Not that I am in favor of inexact size, but I doubt that this claim is true. > Therefore CONVERT.SIZE provides no benefit. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 14:10:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1R7P-0001NI-Lw; Thu, 21 Jun 2007 14:10:55 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1R7O-0001ND-En for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:10:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1R7O-0001N5-5N for lemonade@ietf.org; Thu, 21 Jun 2007 14:10:54 -0400 Received: from 204-174-83-38.static569.dsl.ucc-net.ca ([204.174.83.38] helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1R7M-0005hT-RH for lemonade@ietf.org; Thu, 21 Jun 2007 14:10:54 -0400 Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.1/8.14.1) with ESMTP id l5LIAPuU029005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:10:25 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 21 Jun 2007 11:10:25 -0700 (PDT) From: Lyndon Nerenberg To: Alexey Melnikov Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <467ABD1A.8010107@isode.com> Message-ID: <20070621110732.J28786@orthanc.ca> References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> <20070620131120.P20197@orthanc.ca> <467ABD1A.8010107@isode.com> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,NO_RELAYS autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >> The dialog is not the issue. The issue is that if you're going to guess, >> the client can guess just as well as the server. > > Not that I am in favor of inexact size, but I doubt that this claim is true. Then please explain why x' = F(x) where x is the original part size and F is the function that calculates the estimated size of the converted part would work on the server but not on the client. And I want to see a logically verifiable proof, not a bunch of hand waving. --lyndon This machine is a piece of GAGH! I need dual Pentium processors if I am to do battle with this code! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 14:13:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RA6-0005Sl-Na; Thu, 21 Jun 2007 14:13:42 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1RA6-0005Sg-3w for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:13:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RA5-0005SS-5l for lemonade@ietf.org; Thu, 21 Jun 2007 14:13:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1RA3-0006Mj-9P for lemonade@ietf.org; Thu, 21 Jun 2007 14:13:40 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Jun 2007 19:13:37 +0100 Message-ID: <467ABF7C.50600@isode.com> Date: Thu, 21 Jun 2007 19:12:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lyndon Nerenberg Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> <20070620131120.P20197@orthanc.ca> <467ABD1A.8010107@isode.com> <20070621110732.J28786@orthanc.ca> In-Reply-To: <20070621110732.J28786@orthanc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lyndon Nerenberg wrote: >>> The dialog is not the issue. The issue is that if you're going to >>> guess, the client can guess just as well as the server. >> >> Not that I am in favor of inexact size, but I doubt that this claim >> is true. > > Then please explain why x' = F(x) where x is the original part size > and F is the function that calculates the estimated size of the > converted part would work on the server but not on the client. Function F might depend on the bodypart. Client doesn't have access to it. If it has, then it probably doesn't need CONVERT. > And I want to see a logically verifiable proof, not a bunch of hand > waving. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 14:16:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RCS-0007Ed-3v; Thu, 21 Jun 2007 14:16:08 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1RCQ-0007ET-7C for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RCP-0007EJ-Tq for lemonade@ietf.org; Thu, 21 Jun 2007 14:16:05 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1RCO-0007lF-KF for lemonade@ietf.org; Thu, 21 Jun 2007 14:16:05 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 21 Jun 2007 19:16:02 +0100 Message-ID: <467AC00D.9010508@isode.com> Date: Thu, 21 Jun 2007 19:14:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Crispin Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19DF291B@ILEXC2U01.ndc.lucent.co m> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin wrote: > CONVERT, as I understand it, is a server-based possibly lossy > conversion that is server implementation-dependent (and thus different > compliant servers can convert differently). Correct. > This is NOT something that should be part of the IMAP FETCH framework. (A side note: we really need to document IMAP extensibility framework, include the FETCH command. Any volunteers?) > Most of my objections would become moot if you make this a new command. A disadvantage of this change is that we suddenly need new IMAP URL syntax for converted parts, while before it came for free because IMAP URL was using BODY[section] ABNF. > I'm willing to help out on reforming the design to be a new command, > at least to sketch out syntax. Please. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 14:26:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RMf-00046P-I0; Thu, 21 Jun 2007 14:26:41 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1RMd-00045H-Rr for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RMd-000459-IL for lemonade@ietf.org; Thu, 21 Jun 2007 14:26:39 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1RMc-0001KB-7A for lemonade@ietf.org; Thu, 21 Jun 2007 14:26:39 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5LIQb6J032277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jun 2007 11:26:37 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5LIQY9Z027179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jun 2007 11:26:36 -0700 Date: Thu, 21 Jun 2007 11:26:34 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <467ABF7C.50600@isode.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> <20070620131120.P20197@orthanc.ca> <467ABD1A.8010107@isode.com> <20070621110732.J28786@orthanc.ca> <467ABF7C.50600@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.21.110333 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org, Lyndon Nerenberg X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 21 Jun 2007, Alexey Melnikov wrote: >> Then please explain why x' = F(x) where x is the original part size and >> F is the function that calculates the estimated size of the converted part >> would work on the server but not on the client. > Function F might depend on the bodypart. Client doesn't have access to it. If > it has, then it probably doesn't need CONVERT. The client has access to the BODYSTRUCTURE data for the body part, including the type and its size; otherwise it would not know about the bodypart at all. For Alexey's argument to hold, the actual body part data is needed to produce the estimate. I am unconvinced by a claim that, using the body part data, it is somehow possible to come up with a better estimate than can be done with just the BODYSTRUCTURE data; yet it is somehow extremely difficult to come up with a precise value. That is the claim that needs to be proven. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 14:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RQQ-0005wu-8q; Thu, 21 Jun 2007 14:30:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1RQO-0005wp-Hk for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 14:30:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1RQO-0005wh-8E for lemonade@ietf.org; Thu, 21 Jun 2007 14:30:32 -0400 Received: from 204-174-83-38.static569.dsl.ucc-net.ca ([204.174.83.38] helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1RQM-00038u-Rj for lemonade@ietf.org; Thu, 21 Jun 2007 14:30:32 -0400 Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.1/8.14.1) with ESMTP id l5LIU3Xp029107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 11:30:03 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 21 Jun 2007 11:30:03 -0700 (PDT) From: Lyndon Nerenberg To: Alexey Melnikov Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <467ABF7C.50600@isode.com> Message-ID: <20070621112025.P28786@orthanc.ca> References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> <20070620131120.P20197@orthanc.ca> <467ABD1A.8010107@isode.com> <20070621110732.J28786@orthanc.ca> <467ABF7C.50600@isode.com> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,NO_RELAYS autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > Function F might depend on the bodypart. Client doesn't have access to it. If > it has, then it probably doesn't need CONVERT. Where in that formula does it say anything about the content. The single parameter is size. As I mentioned in my response to Arnt, if the server is going to start parsing the content to create a more accurate estimate, it should just parse the content and generate the exact result size. I fail to see the rational for having support in the server to parse the content -- and this is a pre-requisite to offering the conversion, so that support must be there -- and not using it. The only viable argument I see is that for certain transformations it might be expensive? All I can say is "so what?" If you want to use an expensive service, you pay the expensive price. As I explained earlier, you can defer the work until it's actually needed, and then cache the result. --lyndon Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 15:14:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1S6y-0007ux-HH; Thu, 21 Jun 2007 15:14:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1S6x-0007sW-TN for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1S6x-0007qx-JA for lemonade@ietf.org; Thu, 21 Jun 2007 15:14:31 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1S6w-0006LB-7G for lemonade@ietf.org; Thu, 21 Jun 2007 15:14:31 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l5LJDbec009116; Thu, 21 Jun 2007 14:14:29 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 14:13:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Just say "Yes" Date: Thu, 21 Jun 2007 14:13:52 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19DF3100@ILEXC2U01.ndc.lucent.com> In-Reply-To: <20070621112025.P28786@orthanc.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Just say "Yes" Thread-Index: Ace0MlFVN87tOtg/Qgm7VVC4CTIBGgAAiyFQ From: "Vaudreuil, Greg M \(Greg\)" To: "Alexey Melnikov" X-OriginalArrivalTime: 21 Jun 2007 19:13:52.0713 (UTC) FILETIME=[4E3CE390:01C7B438] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think I've convinced myself that a client-produced estimate may be adequate. Client receives a high-rez picture in image/fancy. It can see this is a 2megabyte file. The user is connected on GPRS, so can plan on using 2 hours of connect time to downaload and 1/2 of the monthly bucket of bandwidth. Bad. Need conversion. The client can accept JPEG's of 160x240, but has no idea how image/fancy converts to JPEG. It cannot estimate the percentage of reduction, but it well could have an internal table with the dozen or so format*resolution combinations it does know and that it can offer that data to the user. There is variation in how large a JPEG of 160x240. To do better, the server will have to examine at least the initial bytes or header of the requested content. For example, the content meta data may show that the image is compressed 20% better than the average for a image/fancy of that resolution. This rough estimate is much less expensive than converting the attachment to find the converted size. However, I'm willing to say that the added accuracy is likely to be low relative to the costs in protocol complexity. Server-provided estimates can also be added in later if we find we need it. If this is acceptable to others, I'd like to see a note added to the document explaining it is a really good idea not to trash the server by asking "what if resolution X, and what if resolution Y, and what if resolution Z", but to make client-side estimates to be presented to the user and only fetch the convert.size when there is an intent to download. Greg V. -----Original Message----- From: Lyndon Nerenberg [mailto:lyndon@orthanc.ca] Sent: Thursday, June 21, 2007 2:30 PM To: Alexey Melnikov Cc: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" > Function F might depend on the bodypart. Client doesn't have access to it. If=20 > it has, then it probably doesn't need CONVERT. Where in that formula does it say anything about the content. The single=20 parameter is size. As I mentioned in my response to Arnt, if the server is going to start=20 parsing the content to create a more accurate estimate, it should just=20 parse the content and generate the exact result size. I fail to see the rational for having support in the server to parse the content -- and this is a pre-requisite to offering the conversion, so that=20 support must be there -- and not using it. The only viable argument I see=20 is that for certain transformations it might be expensive? All I can say=20 is "so what?" If you want to use an expensive service, you pay the=20 expensive price. As I explained earlier, you can defer the work until=20 it's actually needed, and then cache the result. --lyndon Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 16:02:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Srl-0008Py-1U; Thu, 21 Jun 2007 16:02:53 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1Slv-0006Ha-5M for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Slg-00061z-EL for lemonade@ietf.org; Thu, 21 Jun 2007 15:56:39 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SlL-0005XV-Ex for lemonade@ietf.org; Thu, 21 Jun 2007 15:56:18 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 399F14AC1B; Thu, 21 Jun 2007 21:56:14 +0200 (CEST) Message-Id: <3jcLoY6HgyKEn85tIRwntw.md5@libertango.oryx.com> Date: Thu, 21 Jun 2007 21:56:14 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> <20070620131120.P20197@orthanc.ca> <467ABD1A.8010107@isode.com> <20070621110732.J28786@orthanc.ca> In-Reply-To: <20070621110732.J28786@orthanc.ca> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Alexey Melnikov , Lyndon Nerenberg X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Lyndon Nerenberg writes: >>> The dialog is not the issue. The issue is that if you're going to >>> guess, the client can guess just as well as the server. >> >> Not that I am in favor of inexact size, but I doubt that this claim is true. > > Then please explain why x' = F(x) where x is the original part size > and F is the function that calculates the estimated size of the > converted part would work on the server but not on the client. > > And I want to see a logically verifiable proof, not a bunch of hand waving. 1. F is inherently related to the function which actually does the conversion, which is available on the server but not on the client. Conversion from another image format to PNG is a good example: If a server uses the PNG code used in xv, its PNG output will be a lot larger than if the server uses the same library as Adobe Photoshop does (I've seen differences larger than 50%). 2. F need not be F(x), but can be F(actual data) or F(part of the data). For example, one might implement an image conversion F by performing the conversion on one or a few randomly chosen part(s) of the image and multiplying. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 16:25:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TDf-0006CL-9D; Thu, 21 Jun 2007 16:25:31 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1TDe-0006Bd-3g for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TDd-0006BD-Pd for lemonade@ietf.org; Thu, 21 Jun 2007 16:25:29 -0400 Received: from 204-174-83-38.static569.dsl.ucc-net.ca ([204.174.83.38] helo=orthanc.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TDP-0002EX-9l for lemonade@ietf.org; Thu, 21 Jun 2007 16:25:29 -0400 Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.1/8.14.1) with ESMTP id l5LKOjP8029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2007 13:24:45 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 21 Jun 2007 13:24:45 -0700 (PDT) From: Lyndon Nerenberg To: Arnt Gulbrandsen Subject: Re: [lemonade] Just say "Yes" In-Reply-To: <3jcLoY6HgyKEn85tIRwntw.md5@libertango.oryx.com> Message-ID: <20070621130101.A28786@orthanc.ca> References: <89017B166CB7E140BA80577FF744AE19D5606F@ILEXC2U01.ndc.lucent.com> <467928EE.7000603@isode.com> <20070620095721.M20197@orthanc.ca> <20070620124851.M20197@orthanc.ca> <20070620131120.P20197@orthanc.ca> <467ABD1A.8010107@isode.com> <20070621110732.J28786@orthanc.ca> <3jcLoY6HgyKEn85tIRwntw.md5@libertango.oryx.com> Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,NO_RELAYS autolearn=no version=3.2.0 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on orthanc.ca X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: lemonade@ietf.org, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > 1. F is inherently related to the function which actually does the > conversion, which is available on the server but not on the client. > Conversion from another image format to PNG is a good example: If a server > uses the PNG code used in xv, its PNG output will be a lot larger than if the > server uses the same library as Adobe Photoshop does (I've seen differences > larger than 50%). Not only that, but even within a known implementation there will always be cases where the estimate is completely out to lunch. To avoid that, you have to examine the data to at least some degree. Which, once again, brings up back to the issue of partial evaluation of the input vs. complete evaluation of the input. Nobody has yet demonstrated that the incremental cost of full vs. partial evaluation is sufficient to necessitate partial evaluation to begin with. > 2. F need not be F(x), but can be F(actual data) or F(part of the data). For > example, one might implement an image conversion F by performing the > conversion on one or a few randomly chosen part(s) of the image and > multiplying. F is a function that can run equally well on the client or server, and therefore is restricted to having access to the same parameters; practically, this means the contents of ENVELOPE, of which the only useful element is SIZE. But we now seem to be restricting the implementation to those which have access to the source data to be converted. Fine. So will someone please show me a practical example of where a partial-evaluation based estimate will provide any practical savings in the context of an IMAP protocol exchange in the target environment. Remember we are talking a mobile environment, with RTTs in the 10s of milliseconds, and 100s of milliseconds of command/response turnaround when you factor in the transit delay of the actual protocol PDUs. In order for an estimated CONVERT.SIZE to provide a visible benefit over an accurate CONVERT.SIZE, the savings of partial vs. complete evaluation of the conversion needs to save on the order of 100ms of wall clock time. If you're going to justify the need for an estimated CONVERT.SIZE you must demonstrate that this 100ms scenario is going to happen in the real world on an at least semi-regular basis. --lyndon Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 21 19:38:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WEP-0006hb-WF; Thu, 21 Jun 2007 19:38:30 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1WEO-0006ef-QB for lemonade-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 19:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WEO-0006eX-GW for lemonade@ietf.org; Thu, 21 Jun 2007 19:38:28 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1WEN-0000mu-2k for lemonade@ietf.org; Thu, 21 Jun 2007 19:38:28 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5LNcPx5019599 for ; Thu, 21 Jun 2007 16:38:25 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5LNcOH8018253 for ; Thu, 21 Jun 2007 16:38:24 -0700 Received: from 172.24.28.86 ([172.24.28.86]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Jun 2007 23:38:23 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 22 Jun 2007 09:38:22 +1000 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: Off Topic: Why Enterprise Security Matters Thread-Index: Ace0XUERf3+7JCBQEdyISwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [lemonade] Off Topic: Why Enterprise Security Matters X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org http://www.telecoms.com/itmgcontent/tcoms/news/articles/20017434784.html French government bans BlackBerry 21 June 2007 Picture Relating to Story French government officials have been ordered to turn in their BlackBerrys, amid growing security concerns over the popular push email platform. Previously, Germany had banned the device for all officials above a given security classification and other governments and security conscious organisations are expected to do likewise. The concern stems from fundamental design features of the system - even users of BlackBerry Enterprise Server, as opposed to users of RIM's own hosted service, have all the email routed via a RIM data centre. RIM has facilities at its head office in Waterloo, Ontario, in the United States and in London. This heavily centralised architecture is in contrast with essentially all email systems and has been exposed in several single-point-of-failure outages. IT follows that anyone with access to the big server also has access to all the emails passing through. Of course, any RFC822-compliant email server can read the mail passing through, but this is a trivial issue for email within one's own network. IPSec VPNs can be used for access outside that, and public key crypto can be used to secure email to and from external addresses. As a general rule, if anyone can collect absolutely all your traffic, they've got a reasonable chance of breaking the encryption, and can do traffic analysis based on the sources, destinations, times, and quantity of mail. No wonder the French government's infosec advisers are worried. In Sir Peter Wright's memoir 'Spycatcher', he described spending part of the 1960s cracking the French Embassy's encrypted communications with Paris. RIM advertises that its service complies with the US Federal Government's security regulations but this is unlikely to help anyone relax if it's the Feds they're worried about. Canada anyway, is a party to the CAZAB intelligence agreement with the UK, US, Australia and New Zealand, so maybe the French are worried that should they want to bomb a ship in Auckland harbour again, RIM will cc everyone from President Bush to the Directorate of Wool Markets in on the email. To comment on this and other articles, please contact us at chatback@telecoms.com Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 22 04:27:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eU9-0000ds-9v; Fri, 22 Jun 2007 04:27:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1eU8-0000dk-B8 for lemonade-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 04:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eU7-0000dO-UZ for lemonade@ietf.org; Fri, 22 Jun 2007 04:27:15 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1eU5-0007MX-Fi for lemonade@ietf.org; Fri, 22 Jun 2007 04:27:15 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 390554AC1B; Fri, 22 Jun 2007 10:27:12 +0200 (CEST) Message-Id: Date: Fri, 22 Jun 2007 10:27:12 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19DF3100@ILEXC2U01.ndc.lucent.com> In-Reply-To: <89017B166CB7E140BA80577FF744AE19DF3100@ILEXC2U01.ndc.lucent.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: gregv@alcatel-lucent.com, Alexey Melnikov X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org This makes sense to me, a lot of sense. Your message seems to lead to one of these: 1. The size of a converted file can be estimated from the domain size of the data and the format, e.g. image resolution and image format. "An 160*128 image/jpg is usually x-y bytes long". 2. The size of a converted file can be estimated from the same data as in 1, and the same data for input. "An 160*128 image/jpg is usually x-y bytes big. Since the input file is 20% bigger than the average for its resolution and format, we can assume that this one will be x*1.2-y*1.2 bytes". Both seem plausible to me, although I've no idea which is closer to the truth. I'm converting the few hundred images from the London interop to 200*200 pixels width and three formats and will post a followup when the job's done and I've looked at the sizes. (My desktop is fanless and very slow, so things take time.) I'm not sure where this leads. If the client can get the domain size of the input data, it can do the estimate. But it can also get the size from the server, although that may be slow work for the server. In either case the client needs to get something from the server - domain size or estinated target octet size(s). Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 22 05:15:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fEQ-0007oP-PR; Fri, 22 Jun 2007 05:15:06 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1fEP-0007oH-GW for lemonade-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 05:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fEO-0007o9-LP for lemonade@ietf.org; Fri, 22 Jun 2007 05:15:04 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fEN-00016Y-5A for lemonade@ietf.org; Fri, 22 Jun 2007 05:15:04 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id l5M90AS16943 for ; Fri, 22 Jun 2007 10:00:10 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Just say "Yes" Date: Fri, 22 Jun 2007 10:14:15 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80045B033E@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Just say "Yes" Thread-Index: Ace0pxRZeof1vtqlRouQx83JpOBklgABaUEQ References: <89017B166CB7E140BA80577FF744AE19DF3100@ILEXC2U01.ndc.lucent.com> From: "Ben Last" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Arnt Gulbrandsen [mailto:arnt@oryx.com]=20 >Sent: 22 June 2007 09:27 >This makes sense to me, a lot of sense. Your message seems to lead to = one of these: >1. The size of a converted file can be estimated from the domain size = of the data and the format, e.g. >image resolution and image format. "An 160*128 image/jpg is usually x-y = bytes long". True, one could generate a client-side list of formats and typical sizes = and use that, and it would be an effective solution. However, our = client doesn't have a list of accepted formats. The platform (in our = case, S60/Symbian OS) has a list of supported formats, which list will = almost certainly evolve over versions of the platform (it already has). = Thus the process of determining which format is best is based on = matching up two dynamically* generated lists: what the server can = provide and what the platform can support. Our client is merely a = broker between the two, and thus not the place to store a static list of = rules of thumb. Image conversion might be a misleading use case here, since images come = in a reasonably well defined set of standard formats, for which such = rules are easily generated from reference data. How about conversion = from Microsoft's Office 2007 XML format to Word 2003 format (as = supported by many mobile office document viewing clients)? The size of = the converted document is going to be highly content-dependent. Yours pedantically b * By "dynamically", I mean "not reliably predictable at the time of = building the client software". Ben Last R&D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 22 05:52:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1foh-0002Jt-4O; Fri, 22 Jun 2007 05:52:35 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1fof-0002Ji-Ma for lemonade-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 05:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fof-0002Ja-DB for lemonade@ietf.org; Fri, 22 Jun 2007 05:52:33 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fod-0000mJ-VW for lemonade@ietf.org; Fri, 22 Jun 2007 05:52:33 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id D8EEF4AC22; Fri, 22 Jun 2007 11:52:30 +0200 (CEST) Message-Id: Date: Fri, 22 Jun 2007 11:52:30 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Just say "Yes" References: <89017B166CB7E140BA80577FF744AE19DF3100@ILEXC2U01.ndc.lucent.com> <22C8A0D5D5E095449AB509FE777B5F80045B033E@svr-exchange.avocado.emccsoft.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80045B033E@svr-exchange.avocado.emccsoft.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ben Last writes: > True, one could generate a client-side list of formats and typical > sizes and use that, and it would be an effective solution. It wasn't even very effective. The x-y range I mentioned would have to be very large. > However, our client doesn't have a list of accepted formats. The > platform (in our case, S60/Symbian OS) has a list of supported > formats, which list will almost certainly evolve over versions of the > platform (it already has). Thus the process of determining which > format is best is based on matching up two dynamically* generated > lists: what the server can provide and what the platform can support. > Our client is merely a broker between the two, and thus not the place > to store a static list of rules of thumb. Let me guess: You'd rather use CONVERT.SIZE, no matter how expensive that is for the server? Understandable in the circumstances. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 22 05:58:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fuU-0000Kh-LU; Fri, 22 Jun 2007 05:58:34 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1fuT-0000KS-39 for lemonade-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 05:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fuS-0000IY-PA for lemonade@ietf.org; Fri, 22 Jun 2007 05:58:32 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fuR-0002Po-Bp for lemonade@ietf.org; Fri, 22 Jun 2007 05:58:32 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id l5M9hcS22057 for ; Fri, 22 Jun 2007 10:43:39 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Just say "Yes" Date: Fri, 22 Jun 2007 10:57:43 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F80045B03CA@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Just say "Yes" Thread-Index: Ace0sxHLQDtsUG1aSgGKRIMIw4VSGwAADNDQ References: <89017B166CB7E140BA80577FF744AE19DF3100@ILEXC2U01.ndc.lucent.com> <22C8A0D5D5E095449AB509FE777B5F80045B033E@svr-exchange.avocado.emccsoft.com> From: "Ben Last" To: "Arnt Gulbrandsen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >From: Arnt Gulbrandsen [mailto:arnt@oryx.com]=20 >Let me guess: You'd rather use CONVERT.SIZE, no matter how expensive = that is for the server? Understandable in the circumstances. Actually, we have no plans as yet to include document conversion in the = client. It involves a complex UI that has to guide the user through a = number of questions that may make no sense to them. Instead, if the = device can support a format, we show the appropriate icon in the = attachment list. If it can't, we show a "?" icon. The user guide = explains the difference. No user has seen this as a problem; initial = feedback is that it's very, very rare that users look at attachments on = their mobile devices (though that behaviour will no doubt evolve over = time with the device capabilities). Thus I'm following this debate from a somewhat more neutral standpoint = than usual, though with a client-side-development attitude :) cheers Ben _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 22 09:29:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jCN-0003rZ-95; Fri, 22 Jun 2007 09:29:15 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1jCL-0003rP-Ni for lemonade-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 09:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jCL-0003rH-EB for lemonade@ietf.org; Fri, 22 Jun 2007 09:29:13 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jCK-0007uM-2U for lemonade@ietf.org; Fri, 22 Jun 2007 09:29:13 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5MDSEY6029134 for ; Fri, 22 Jun 2007 08:29:09 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:28:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Just say "Yes" Date: Fri, 22 Jun 2007 08:28:58 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19E2B7F2@ILEXC2U01.ndc.lucent.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80045B033E@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Just say "Yes" Thread-Index: Ace0pxRZeof1vtqlRouQx83JpOBklgABaUEQAAgX0pA= From: "Vaudreuil, Greg M \(Greg\)" To: X-OriginalArrivalTime: 22 Jun 2007 13:28:58.0415 (UTC) FILETIME=[49E35BF0:01C7B4D1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A colleague of mine pointed out that my earlier post accepting = client-side estimates missed an important use-case around time-based = media. If a client knows a file is 2meg in MP3 format, and it requests the = audio in AMR format, it has no ability to guess the converted object = size. MP3 can be encoded in a wide variety of bit-rates. The client can figure the size if it knows the duration of the media in = the object and the average bit-rate of an AMR codec, but duration is an = optional MIME parameter that in my experience is rarely populated = outside of voicemail. So, the client needs richer information, not just the output format, but = also a way of interpreting the input (original) size relative to the = encoding. This throws me back over the fence... a lightweight client can't be = expected to know all the likely input formats. It needs server support. That support may be different than the current proposal, that is, maybe = we can introduce a command to fetch a dynamic list of conversion ratio's = as part of learning the servers capabilities. =20 Greg V.=20 -----Original Message----- From: Ben Last [mailto:Ben.Last@emccsoft.com] Sent: Friday, June 22, 2007 5:14 AM To: lemonade@ietf.org Subject: RE: [lemonade] Just say "Yes" >From: Arnt Gulbrandsen [mailto:arnt@oryx.com]=20 >Sent: 22 June 2007 09:27 >This makes sense to me, a lot of sense. Your message seems to lead to = one of these: >1. The size of a converted file can be estimated from the domain size = of the data and the format, e.g. >image resolution and image format. "An 160*128 image/jpg is usually x-y = bytes long". True, one could generate a client-side list of formats and typical sizes = and use that, and it would be an effective solution. However, our = client doesn't have a list of accepted formats. The platform (in our = case, S60/Symbian OS) has a list of supported formats, which list will = almost certainly evolve over versions of the platform (it already has). = Thus the process of determining which format is best is based on = matching up two dynamically* generated lists: what the server can = provide and what the platform can support. Our client is merely a = broker between the two, and thus not the place to store a static list of = rules of thumb. Image conversion might be a misleading use case here, since images come = in a reasonably well defined set of standard formats, for which such = rules are easily generated from reference data. How about conversion = from Microsoft's Office 2007 XML format to Word 2003 format (as = supported by many mobile office document viewing clients)? The size of = the converted document is going to be highly content-dependent. Yours pedantically b * By "dynamically", I mean "not reliably predictable at the time of = building the client software". Ben Last R&D Manager EMCC Software Ltd _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 22 11:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1lTu-0003mP-7j; Fri, 22 Jun 2007 11:55:30 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I1lTs-0003lu-Jk for lemonade-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 11:55:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1lTs-0003kw-8t for lemonade@ietf.org; Fri, 22 Jun 2007 11:55:28 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1lTq-0000d2-V8 for lemonade@ietf.org; Fri, 22 Jun 2007 11:55:28 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l5MFtObR019266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jun 2007 08:55:24 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l5MFtLps007472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2007 08:55:23 -0700 Date: Fri, 22 Jun 2007 08:55:21 -0700 (PDT) From: Mark Crispin To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] Just say "Yes" In-Reply-To: <89017B166CB7E140BA80577FF744AE19E2B7F2@ILEXC2U01.ndc.lucent.com> Message-ID: References: <89017B166CB7E140BA80577FF744AE19E2B7F2@ILEXC2U01.ndc.lucent.co m> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.22.83432 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Fri, 22 Jun 2007, Vaudreuil, Greg M (Greg) wrote: > This throws me back over the fence... a lightweight client can't be expected to know all the likely input formats. It needs server support. In which case, require that the server calculate and report the exact size. It is a server implementation problem to render the cost reasonable. A lie is worse than no information at all. NNTP lies, and those lies present a major hassles for me that are ameliorating only because netnews is dying. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Jun 24 15:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XNg-0007GG-Hw; Sun, 24 Jun 2007 15:04:16 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I2XNf-0007GB-R6 for lemonade-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 15:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2XNf-0007G3-HS for lemonade@ietf.org; Sun, 24 Jun 2007 15:04:15 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2XNe-0004Dl-5I for lemonade@ietf.org; Sun, 24 Jun 2007 15:04:15 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5OJ4CSr023254 for ; Sun, 24 Jun 2007 12:04:12 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5OJ3soj024784 for ; Sun, 24 Jun 2007 12:03:54 -0700 Received: from 172.24.28.182 ([172.24.28.182]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Sun, 24 Jun 2007 19:04:10 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 24 Jun 2007 12:04:09 -0700 From: Eric Burger To: "lemonade@ietf.org" Message-ID: Thread-Topic: CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [lemonade] CONVERT - Clients Do Not Know X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I would offer that we should be able to have consensus that clients CANNOT know size estimates, as it is HIGHLY unlikely for clients to understand the source format. If they understand the source format, there is a good chance they can accept the source format. I would like to ask a sanity check question: who REALLY is going to offer the user the option of which converted-to format to download? My assertion is most of the time the device will decide for the user, i.e., "file is in image/foo, I only understand image/png, so please convert," or, "image is 1960x1400 at 16-bit depth, I can only render 320x240 at 8-bit depth, so please convert." If Joe Average user is going to be asked, is he going to be asked anything other than, "Do you want the original document or something you can read?" Said another way, would it be correct to assert conversion was for display size, audio/video quality, or object format, and NOT for transmission optimization? I am leaning towards Lyndon's position: since there is no real use case for SIZE as an estimator, let us let the server only offer it to the client when it knows the exact value, after conversion. OTHERWISE, I would offer a mega ugly solution: include conversion ESTIMATES in the BODYSTRUCTURE response. That will save a bunch of RTTs. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Sun Jun 24 16:57:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Z98-0001h6-8d; Sun, 24 Jun 2007 16:57:22 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I2Z96-0001bM-OO for lemonade-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 16:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Z96-0001as-Ea; Sun, 24 Jun 2007 16:57:20 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2Z94-0004Go-JN; Sun, 24 Jun 2007 16:57:20 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm132467ede60; Mon, 25 Jun 2007 05:08:48 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm5e4679f322; Thr, 21 Jun 2007 08:05:52 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 21 Jun 2007 08:05:52 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I190B-0007ma-GO; Wed, 20 Jun 2007 18:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18zz-0007GC-Pz; Wed, 20 Jun 2007 18:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I18zy-0005HX-BN; Wed, 20 Jun 2007 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 30BA7328EB; Wed, 20 Jun 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I18zy-0005hm-2x; Wed, 20 Jun 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 20 Jun 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.2 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-09.txt X-BeenThere: lemonade@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF. Title : Deployment Considerations for lemonade-compliant Mobile Email Author(s) : R. Gellens Filename : draft-ietf-lemonade-deployments-09.txt Pages : 14 Date : 2007-6-20 This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-deployments-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-deployments-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-20153513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-deployments-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-deployments-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-20153513.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade --NextPart-- From lemonade-bounces@ietf.org Mon Jun 25 04:36:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2k3N-0002id-6d; Mon, 25 Jun 2007 04:36:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I2k3L-0002iU-Oq for lemonade-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 04:36:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2k3L-0002iM-Cj for lemonade@ietf.org; Mon, 25 Jun 2007 04:36:07 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2k3J-0004zl-KI for lemonade@ietf.org; Mon, 25 Jun 2007 04:36:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5P8ZvwS025790; Mon, 25 Jun 2007 11:36:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 11:35:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 11:35:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] CONVERT - Clients Do Not Know Date: Mon, 25 Jun 2007 11:35:44 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157B76605@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/wAcQ5WA References: From: To: , X-OriginalArrivalTime: 25 Jun 2007 08:35:59.0028 (UTC) FILETIME=[DAFF0740:01C7B703] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Eric, >I would like to ask a sanity check question: who REALLY is=20 >going to offer the user the option of which converted-to=20 >format to download? My assertion is most of the time the=20 >device will decide for the user, i.e., "file is in image/foo,=20 >I only understand image/png, so please convert," or, "image is=20 >1960x1400 at 16-bit depth, I can only render 320x240 at 8-bit=20 >depth, so please convert." Do You mean format, size or both? _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 25 10:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pYI-00027V-OM; Mon, 25 Jun 2007 10:28:26 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I2pYH-00027O-4o for lemonade-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 10:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pYG-00027C-RS for lemonade@ietf.org; Mon, 25 Jun 2007 10:28:24 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2pYF-000277-IZ for lemonade@ietf.org; Mon, 25 Jun 2007 10:28:24 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 25 Jun 2007 15:27:20 +0100 Message-ID: <467D1CB2.9060402@isode.com> Date: Sat, 23 Jun 2007 14:14:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lemonade WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [lemonade] Another [short] WGLC on IMAP CONTEXT X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi everybody, Dave just posted draft-cridland-imap-context-03.txt, which I believe addresses all issues raised so far, including some extra issues from Peter Coates and myself. Please review this version before July 2nd. If I don't see any new serious issues, I will ask Chris to publish this document. Thanks, Alexey, acting as the Lemonade WG Secretary. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Mon Jun 25 17:50:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2wRv-0004Sh-0l; Mon, 25 Jun 2007 17:50:19 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I2wRt-0004SU-8o for lemonade-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 17:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2wRs-0004SM-VX for lemonade@ietf.org; Mon, 25 Jun 2007 17:50:16 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2wRr-0006eM-HL for lemonade@ietf.org; Mon, 25 Jun 2007 17:50:16 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5PLoDAn020326; Mon, 25 Jun 2007 14:50:13 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5PLnshs007024; Mon, 25 Jun 2007 14:49:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [lemonade] CONVERT - Clients Do Not Know Date: Mon, 25 Jun 2007 14:50:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/wAcQ5WAABvTmfo= From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Most likely, "please convert to image/png at 320x240" which may or may not involve size or format conversion. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. -----Original Message----- From: Zoltan.Ordogh@nokia.com To: Eric Burger; lemonade@ietf.org Sent: Mon Jun 25 01:35:44 2007 Subject: RE: [lemonade] CONVERT - Clients Do Not Know Hi Eric, >I would like to ask a sanity check question: who REALLY is >going to offer the user the option of which converted-to >format to download? My assertion is most of the time the >device will decide for the user, i.e., "file is in image/foo, >I only understand image/png, so please convert," or, "image is >1960x1400 at 16-bit depth, I can only render 320x240 at 8-bit >depth, so please convert." Do You mean format, size or both? Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 26 06:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I38BR-0006nX-L5; Tue, 26 Jun 2007 06:22:05 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I38BQ-0006nO-RP for lemonade-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 06:22:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I38BQ-0006n7-75 for lemonade@ietf.org; Tue, 26 Jun 2007 06:22:04 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I38BP-0005wi-PZ for lemonade@ietf.org; Tue, 26 Jun 2007 06:22:04 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5QALGbN007888; Tue, 26 Jun 2007 13:21:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 13:21:18 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 13:21:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] CONVERT - Clients Do Not Know Date: Tue, 26 Jun 2007 13:21:03 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157BBE728@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/wAcQ5WAABvTmfoAGf4Z8A== References: From: To: , X-OriginalArrivalTime: 26 Jun 2007 10:21:18.0162 (UTC) FILETIME=[BBE81B20:01C7B7DB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Or, "please convert to image/png or image/jpg but no more than 1megabytes"? = (server decides image resolution) "please convert to 320x240 but no more than 10kilobytes"? (server = decides a format based on info about client and suitable compression = that provides <10k) I think mobile devices are more likely to convert due to attachment size = limit than convert due to image resolution/format. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Eric Burger [mailto:eburger@bea.com]=20 >Sent: 26 June, 2007 00:50 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org >Subject: Re: [lemonade] CONVERT - Clients Do Not Know > >Most likely, "please convert to image/png at 320x240" which=20 >may or may not involve size or format conversion. > >-- >Sent from my wireless e-mail device. Sorry if terse. We all=20 >need lemonade: see=20 > for what lemonade is. > >-----Original Message----- >From: Zoltan.Ordogh@nokia.com >To: Eric Burger; lemonade@ietf.org >Sent: Mon Jun 25 01:35:44 2007 >Subject: RE: [lemonade] CONVERT - Clients Do Not Know > >Hi Eric, > >>I would like to ask a sanity check question: who REALLY is going to=20 >>offer the user the option of which converted-to format to=20 >download? My=20 >>assertion is most of the time the device will decide for the user,=20 >>i.e., "file is in image/foo, I only understand image/png, so please=20 >>convert," or, "image is 1960x1400 at 16-bit depth, I can only render=20 >>320x240 at 8-bit depth, so please convert." > >Do You mean format, size or both? > >Notice: This email message, together with any attachments,=20 >may contain information of BEA Systems, Inc., its=20 >subsidiaries and affiliated entities, that may be=20 >confidential, proprietary, copyrighted and/or legally=20 >privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the=20 >intended recipient, and have received this message in error,=20 >please immediately return this by email and then delete it. > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 26 06:39:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I38Rq-0003bh-PE; Tue, 26 Jun 2007 06:39:02 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I38Rp-0003b6-4R for lemonade-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 06:39:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I38Ro-0003ay-Qc for lemonade@ietf.org; Tue, 26 Jun 2007 06:39:00 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I38Ro-00087q-Ds for lemonade@ietf.org; Tue, 26 Jun 2007 06:39:00 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5QAcTO6023457; Tue, 26 Jun 2007 13:38:42 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 13:38:25 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 13:38:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Another [short] WGLC on IMAP CONTEXT Date: Tue, 26 Jun 2007 13:38:10 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157BBE758@esebe199.NOE.Nokia.com> In-Reply-To: <467D1CB2.9060402@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Another [short] WGLC on IMAP CONTEXT Thread-Index: Ace3NR7n1EpJaDHGQ5Se4j6vX8347AAqOtCQ References: <467D1CB2.9060402@isode.com> From: To: , X-OriginalArrivalTime: 26 Jun 2007 10:38:25.0615 (UTC) FILETIME=[2050FDF0:01C7B7DE] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Looking good. (Just saying yes.) Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 23 June, 2007 16:14 >To: Lemonade WG >Subject: [lemonade] Another [short] WGLC on IMAP CONTEXT > >Hi everybody, >Dave just posted draft-cridland-imap-context-03.txt, which I=20 >believe addresses all issues raised so far, including some=20 >extra issues from Peter Coates and myself. > >Please review this version before July 2nd. If I don't see any=20 >new serious issues, I will ask Chris to publish this document. > >Thanks, >Alexey, acting as the Lemonade WG Secretary. > > > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 26 10:43:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CGL-0001hw-HT; Tue, 26 Jun 2007 10:43:25 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I3CGK-0001dh-G0 for lemonade-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 10:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CGK-0001ah-3l for lemonade@ietf.org; Tue, 26 Jun 2007 10:43:24 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CFo-0000k1-0c for lemonade@ietf.org; Tue, 26 Jun 2007 10:43:23 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5QEgOla006255; Tue, 26 Jun 2007 09:42:51 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 09:42:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Another [short] WGLC on IMAP CONTEXT Date: Tue, 26 Jun 2007 09:42:01 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19E2C3DA@ILEXC2U01.ndc.lucent.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157BBE758@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Another [short] WGLC on IMAP CONTEXT Thread-Index: Ace3NR7n1EpJaDHGQ5Se4j6vX8347AAqOtCQAAiCgLA= From: "Vaudreuil, Greg M \(Greg\)" To: , X-OriginalArrivalTime: 26 Jun 2007 14:42:26.0888 (UTC) FILETIME=[3731F480:01C7B800] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I have read the draft and see no issues. Greg V. -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Tuesday, June 26, 2007 6:38 AM To: alexey.melnikov@isode.com; lemonade@ietf.org Subject: RE: [lemonade] Another [short] WGLC on IMAP CONTEXT Looking good. (Just saying yes.) Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 23 June, 2007 16:14 >To: Lemonade WG >Subject: [lemonade] Another [short] WGLC on IMAP CONTEXT > >Hi everybody, >Dave just posted draft-cridland-imap-context-03.txt, which I=20 >believe addresses all issues raised so far, including some=20 >extra issues from Peter Coates and myself. > >Please review this version before July 2nd. If I don't see any=20 >new serious issues, I will ask Chris to publish this document. > >Thanks, >Alexey, acting as the Lemonade WG Secretary. > > > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Tue Jun 26 16:55:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3I4C-0001F2-JK; Tue, 26 Jun 2007 16:55:16 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I3I4A-0001Ex-T0 for lemonade-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 16:55:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3I4A-0001EM-Ir for lemonade@ietf.org; Tue, 26 Jun 2007 16:55:14 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3I4A-0003T4-2w for lemonade@ietf.org; Tue, 26 Jun 2007 16:55:14 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5QKrO12023524 for ; Tue, 26 Jun 2007 15:53:25 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 15:53:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jun 2007 15:53:07 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19E65223@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Profile Bis updated Thread-Index: AceXdbM+K2vvzBq+QJ6KRE2Xq0stmggvX+cw From: "Vaudreuil, Greg M \(Greg\)" To: "Enhancements to Internet email to support diverse service enivronments" X-OriginalArrivalTime: 26 Jun 2007 20:53:24.0768 (UTC) FILETIME=[09ECEA00:01C7B834] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [lemonade] Future Release in LEMONADE Profile bis? X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I reviewed the minutes and list, but don't see clearly if we agreed that future-release was to be included in the Ph-2 LEMONADE profile. There was plenty of debate as to whether the extension should be worked as a formal WG item or not, with a flip-flop-flip in the history. That document is now done, RFC 4865. I'd like to suggest that future-release is included in Profile-BIS. It is a simple extension with high utility to a diverse client, especially with intermittent connectivity or subject to unforseen battery exhaustion. In general, fewer options are better than more, and this is an extension I expect to be widely implemented regardless of whether it is in LEMONADE or not. Not including simply requires supporting another code-path in the client and another diverse user experience :-( Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jun 27 16:41:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eKq-00080A-5z; Wed, 27 Jun 2007 16:41:56 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I3eKo-0007yU-O8 for lemonade-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 16:41:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eKo-0007x1-Dl; Wed, 27 Jun 2007 16:41:54 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3eKo-0005aw-69; Wed, 27 Jun 2007 16:41:54 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 22C7C2AC92; Wed, 27 Jun 2007 20:41:24 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3eKJ-0007Ph-Qg; Wed, 27 Jun 2007 16:41:23 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 27 Jun 2007 16:41:23 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: lemonade mailing list , lemonade chair , Internet Architecture Board , RFC Editor Subject: [lemonade] Protocol Action: 'Deployment Considerations for lemonade-compliant Mobile Email' to BCP X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The IESG has approved the following document: - 'Deployment Considerations for lemonade-compliant Mobile Email ' as a BCP This document is the product of the Enhancements to Internet email to Support Diverse Service Environments Working Group. The IESG contact persons are Chris Newman and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-09.txt Technical Summary This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. Working Group Summary There is consensus in the WG to publish this document. Document Quality Virtually all members of the Lemonade WG have reviewed the document. The document has been checked manually and using idnits 1.118, and passed both checks. Eric Burger shepherds this document. Ted Hardie and Chris Newman reviewed this document for the IESG. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 28 16:33:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40gG-0006oB-DG; Thu, 28 Jun 2007 16:33:32 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I40gF-0006o6-RE for lemonade-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 16:33:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40gF-0006ny-G6 for lemonade@ietf.org; Thu, 28 Jun 2007 16:33:31 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I40gF-0008Ba-2p for lemonade@ietf.org; Thu, 28 Jun 2007 16:33:31 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5SKWvK7025664 for ; Thu, 28 Jun 2007 13:32:57 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5SKWtLu020320 for ; Thu, 28 Jun 2007 13:32:56 -0700 Received: from 172.24.28.103 ([172.24.28.103]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jun 2007 20:32:55 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 28 Jun 2007 13:32:55 -0700 Subject: Re: [lemonade] CONVERT - Clients Do Not Know From: Eric Burger To: Message-ID: Thread-Topic: [lemonade] CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/wAcQ5WAABvTmfoAGf4Z8AB6LsWY In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157BBE728@esebe199.NOE.Nokia.com> Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Thoughts on the idea of maximum size (or suggested size) as the parameter, rather than format? On 6/26/07 3:21 AM, "Zoltan.Ordogh@nokia.com" wrote: > Or, > "please convert to image/png or image/jpg but no more than 1megabytes"? > (server decides image resolution) > "please convert to 320x240 but no more than 10kilobytes"? (server decides= a > format based on info about client and suitable compression that provides = <10k) >=20 > I think mobile devices are more likely to convert due to attachment size = limit > than convert due to image resolution/format. >=20 > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 >=20 >=20 >=20 >> -----Original Message----- >> From: ext Eric Burger [mailto:eburger@bea.com] >> Sent: 26 June, 2007 00:50 >> To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org >> Subject: Re: [lemonade] CONVERT - Clients Do Not Know >>=20 >> Most likely, "please convert to image/png at 320x240" which >> may or may not involve size or format conversion. >>=20 >> -- >> Sent from my wireless e-mail device. Sorry if terse. We all >> need lemonade: see >> for what lemonade is. >>=20 >> -----Original Message----- >> From: Zoltan.Ordogh@nokia.com >> To: Eric Burger; lemonade@ietf.org >> Sent: Mon Jun 25 01:35:44 2007 >> Subject: RE: [lemonade] CONVERT - Clients Do Not Know >>=20 >> Hi Eric, >>=20 >>> I would like to ask a sanity check question: who REALLY is going to >>> offer the user the option of which converted-to format to >> download? My >>> assertion is most of the time the device will decide for the user, >>> i.e., "file is in image/foo, I only understand image/png, so please >>> convert," or, "image is 1960x1400 at 16-bit depth, I can only render >>> 320x240 at 8-bit depth, so please convert." >>=20 >> Do You mean format, size or both? >>=20 >> Notice: This email message, together with any attachments, >> may contain information of BEA Systems, Inc., its >> subsidiaries and affiliated entities, that may be >> confidential, proprietary, copyrighted and/or legally >> privileged, and is intended solely for the use of the >> individual or entity named in this message. If you are not the >> intended recipient, and have received this message in error, >> please immediately return this by email and then delete it. >>=20 >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 28 16:35:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40hx-0008Nf-Gh; Thu, 28 Jun 2007 16:35:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I40hx-0008NS-0b for lemonade-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 16:35:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40hw-0008Mm-LF for lemonade@ietf.org; Thu, 28 Jun 2007 16:35:16 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I40hw-0008Hf-8m for lemonade@ietf.org; Thu, 28 Jun 2007 16:35:16 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5SKZCYR028030; Thu, 28 Jun 2007 13:35:12 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5SKYqJV012290; Thu, 28 Jun 2007 13:34:52 -0700 Received: from 172.24.28.103 ([172.24.28.103]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jun 2007 20:35:11 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 28 Jun 2007 13:35:11 -0700 Subject: Re: [lemonade] Future Release in LEMONADE Profile bis? From: Eric Burger To: "Vaudreuil, Greg M (Greg)" Message-ID: Thread-Topic: [lemonade] Future Release in LEMONADE Profile bis? Thread-Index: AceXdbM+K2vvzBq+QJ6KRE2Xq0stmggvX+cwAGQn/W4= In-Reply-To: <89017B166CB7E140BA80577FF744AE19E65223@ILEXC2U01.ndc.lucent.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I don't see it that way, unless one is creating a "Lemonade client" that does not follow standard IMAP and assumes features are there, and thus Future Delivery, if not in the Profile, is clearly a weird thing. If one creates clients that happen to implement lemonade, and they want to do future delivery, they just do future delivery. What could possibly go wrong? On 6/26/07 1:53 PM, "Vaudreuil, Greg M (Greg)" wrote: > > I reviewed the minutes and list, but don't see clearly if we agreed that > future-release was to be included in the Ph-2 LEMONADE profile. There > was plenty of debate as to whether the extension should be worked as a > formal WG item or not, with a flip-flop-flip in the history. That > document is now done, RFC 4865. > > I'd like to suggest that future-release is included in Profile-BIS. It > is a simple extension with high utility to a diverse client, especially > with intermittent connectivity or subject to unforseen battery > exhaustion. In general, fewer options are better than more, and this is > an extension I expect to be widely implemented regardless of whether it > is in LEMONADE or not. Not including simply requires supporting another > code-path in the client and another diverse user experience :-( > > Greg V. > > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Thu Jun 28 16:55:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I411x-00029b-9k; Thu, 28 Jun 2007 16:55:57 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I411w-00024v-6q for lemonade-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 16:55:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I411v-00024F-TC for lemonade@ietf.org; Thu, 28 Jun 2007 16:55:55 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4112-0004Sk-Kk for lemonade@ietf.org; Thu, 28 Jun 2007 16:55:55 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5SKsxk3015762 for ; Thu, 28 Jun 2007 13:54:59 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5SKsvI7014509 for ; Thu, 28 Jun 2007 13:54:57 -0700 Received: from 172.24.28.103 ([172.24.28.103]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jun 2007 20:54:57 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 28 Jun 2007 13:54:57 -0700 From: Eric Burger To: Enhancements to Internet email to support diverse service enivronments Message-ID: Thread-Topic: Updated IETF 69 Schedule Thread-Index: Ace5xpW51IM4+CW5EdyWbAAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [lemonade] Updated IETF 69 Schedule X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org If you are new, or want a refresher, I would suggest attending some of the tutorials: SUNDAY, July 22, 2007 1300-1445 Newcomer's Training - Crystal 1300-1445 What Should Spec Writers Know about IPv6? - Monroe 1500-1645 Writing an RFC: The Definitive Guide by the RFC Editor - State Ballroom 1500-1645 Intro to IETF Tools - Monroe Of course, you want to make sure to visit the... 1700-1900 Welcome Reception - Grand Ballroom MONDAY, July 23, 2007 1300-1500 Afternoon Session I Monroe APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG TUESDAY, July 24, 2007 Crystal APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 29 05:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4CRh-0001w0-1z; Fri, 29 Jun 2007 05:07:17 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I4CRf-0001vu-Qp for lemonade-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 05:07:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4CRe-0001vm-VE for lemonade@ietf.org; Fri, 29 Jun 2007 05:07:14 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4CRa-0007Gs-9M for lemonade@ietf.org; Fri, 29 Jun 2007 05:07:14 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id l5T8qCS15930 for ; Fri, 29 Jun 2007 09:52:12 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] CONVERT - Clients Do Not Know Date: Fri, 29 Jun 2007 10:06:16 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F800464C393@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/wAcQ5WAABvTmfoAGf4Z8AB6LsWYABlmUHA= References: <4C38DC11F6B4FF4FAEA73E30DB5AA157BBE728@esebe199.NOE.Nokia.com> From: "Ben Last" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Not sure it helps. Yes, for images it's a reasonable approach, though I = think there's other information that a converter would find useful, like = pixel depth, resolution, etc. But for other document formats, where = conversion must be lossless, I'm not sure how a client can sensibly = provide the server with a reasonable value. On the subject of whether size or format is more likely as a client = constraint: the amount of storage usable is a dynamically variable value = (up to the full amount available, but varies depending on other = processes on the device, and whether the client has any form of smart = storage management). A format is either supported or not. There's a wider issue here about using images as the only use case when = discussing this. I'd prefer to use (or at least include): * voice audio, as for voicemail-to-email setups * music or other higher-quality audio * documents in MS Office format (for better or worse, a de facto = standard) * PDFs, both those in vector format and those containing bitmaps * Full webpages sent as attachments (in the Outlook/IE format that = packages all images and HTML) Further use cases left as an exercise for the massed minds of = Lemonade... regards Ben Ben Last R&D Manager EMCC Software -----Original Message----- From: Eric Burger [mailto:eburger@bea.com]=20 Sent: 28 June 2007 21:33 To: lemonade@ietf.org Subject: Re: [lemonade] CONVERT - Clients Do Not Know Thoughts on the idea of maximum size (or suggested size) as the = parameter, rather than format? On 6/26/07 3:21 AM, "Zoltan.Ordogh@nokia.com" wrote: > Or, > "please convert to image/png or image/jpg but no more than = 1megabytes"? > (server decides image resolution) > "please convert to 320x240 but no more than 10kilobytes"? (server=20 > decides a format based on info about client and suitable compression=20 > that provides <10k) >=20 > I think mobile devices are more likely to convert due to attachment=20 > size limit than convert due to image resolution/format. >=20 > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 >=20 >=20 >=20 >> -----Original Message----- >> From: ext Eric Burger [mailto:eburger@bea.com] >> Sent: 26 June, 2007 00:50 >> To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org >> Subject: Re: [lemonade] CONVERT - Clients Do Not Know >>=20 >> Most likely, "please convert to image/png at 320x240" which may or=20 >> may not involve size or format conversion. >>=20 >> -- >> Sent from my wireless e-mail device. Sorry if terse. We all need=20 >> lemonade: see for what=20 >> lemonade is. >>=20 >> -----Original Message----- >> From: Zoltan.Ordogh@nokia.com >> To: Eric Burger; lemonade@ietf.org >> Sent: Mon Jun 25 01:35:44 2007 >> Subject: RE: [lemonade] CONVERT - Clients Do Not Know >>=20 >> Hi Eric, >>=20 >>> I would like to ask a sanity check question: who REALLY is going to=20 >>> offer the user the option of which converted-to format to >> download? My >>> assertion is most of the time the device will decide for the user,=20 >>> i.e., "file is in image/foo, I only understand image/png, so please=20 >>> convert," or, "image is 1960x1400 at 16-bit depth, I can only render = >>> 320x240 at 8-bit depth, so please convert." >>=20 >> Do You mean format, size or both? >>=20 >> Notice: This email message, together with any attachments, may=20 >> contain information of BEA Systems, Inc., its subsidiaries and =20 >> affiliated entities, that may be confidential, proprietary, =20 >> copyrighted and/or legally privileged, and is intended solely for=20 >> the use of the individual or entity named in this message. If you are = >> not the intended recipient, and have received this message in error,=20 >> please immediately return this by email and then delete it. >>=20 >=20 Notice: This email message, together with any attachments, may contain = information of BEA Systems, Inc., its subsidiaries and affiliated = entities, that may be confidential, proprietary, copyrighted and/or = legally privileged, and is intended solely for the use of the individual = or entity named in this message. If you are not the intended recipient, = and have received this message in error, please immediately return this = by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 29 05:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DB3-0006Dj-BJ; Fri, 29 Jun 2007 05:54:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I4DB2-0006DY-5W for lemonade-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 05:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DB1-0006DO-Ez for lemonade@ietf.org; Fri, 29 Jun 2007 05:54:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4DAv-0004ik-0r for lemonade@ietf.org; Fri, 29 Jun 2007 05:54:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5T9rWGe027295; Fri, 29 Jun 2007 12:53:54 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 12:53:29 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 12:53:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] CONVERT - Clients Do Not Know Date: Fri, 29 Jun 2007 12:53:13 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157BF6D5E@esebe199.NOE.Nokia.com> In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F800464C393@svr-exchange.avocado.emccsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/wAcQ5WAABvTmfoAGf4Z8AB6LsWYABlmUHAAAksGcA== References: <4C38DC11F6B4FF4FAEA73E30DB5AA157BBE728@esebe199.NOE.Nokia.com> <22C8A0D5D5E095449AB509FE777B5F800464C393@svr-exchange.avocado.emccsoft.com> From: To: , X-OriginalArrivalTime: 29 Jun 2007 09:53:29.0879 (UTC) FILETIME=[58C59270:01C7BA33] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Ben, >-----Original Message----- >From: ext Ben Last [mailto:Ben.Last@emccsoft.com]=20 >Sent: 29 June, 2007 12:06 >To: lemonade@ietf.org >Subject: RE: [lemonade] CONVERT - Clients Do Not Know > >Not sure it helps. Yes, for images it's a reasonable=20 >approach, though I think there's other information that a=20 >converter would find useful, like pixel depth, resolution,=20 >etc. But for other document formats, where conversion must be=20 >lossless, I'm not sure how a client can sensibly provide the=20 >server with a reasonable value. > >On the subject of whether size or format is more likely as a=20 >client constraint: the amount of storage usable is a=20 >dynamically variable value (up to the full amount available,=20 >but varies depending on other processes on the device, and=20 >whether the client has any form of smart storage management). =20 >A format is either supported or not. > >There's a wider issue here about using images as the only use=20 >case when discussing this. I'd prefer to use (or at least include): >* voice audio, as for voicemail-to-email setups >* music or other higher-quality audio >* documents in MS Office format (for better or worse, a de=20 >facto standard) >* PDFs, both those in vector format and those containing bitmaps >* Full webpages sent as attachments (in the Outlook/IE format=20 >that packages all images and HTML) I fully agree with You. I came up with this idea - regarding images only = in the first place - because I took a photo and wanted to send it over = to a friend via MMS, and I had to convert it manually several times = (crop, downscale, crop again) before I got it the right size (<=3D300k = but acceptable quality). I foresee something similar when = sending/fetching emails: client storage limit (for fetch), outgoing mail = size limit by operator (for send) - and I would not want to go trough = such hassle whenever I want to send an image. There should not be any problem adding size limit to other formats - = providing that it is the conclusion of the working group since it is = only an idea at this point. The only problem I could foresee is lossless conversion with size limit = - this should be either: - forbidden (or not applicable combo), - ignore lossless flag (for pictures or similar data) - cut when size reached (streams). > >Further use cases left as an exercise for the massed minds of=20 >Lemonade... > >regards >Ben > >Ben Last >R&D Manager >EMCC Software > >-----Original Message----- >From: Eric Burger [mailto:eburger@bea.com] >Sent: 28 June 2007 21:33 >To: lemonade@ietf.org >Subject: Re: [lemonade] CONVERT - Clients Do Not Know > >Thoughts on the idea of maximum size (or suggested size) as=20 >the parameter, rather than format? > > >On 6/26/07 3:21 AM, "Zoltan.Ordogh@nokia.com" >wrote: > >> Or, >> "please convert to image/png or image/jpg but no more than=20 >1megabytes"? >> (server decides image resolution) >> "please convert to 320x240 but no more than 10kilobytes"? (server=20 >> decides a format based on info about client and suitable compression=20 >> that provides <10k) >>=20 >> I think mobile devices are more likely to convert due to attachment=20 >> size limit than convert due to image resolution/format. >>=20 >> Best regards: Zolt=E1n =D6rd=F6gh >> E-mail: zoltan dot ordogh at nokia dot com >> Phone: +358 50 386 0566 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: ext Eric Burger [mailto:eburger@bea.com] >>> Sent: 26 June, 2007 00:50 >>> To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org >>> Subject: Re: [lemonade] CONVERT - Clients Do Not Know >>>=20 >>> Most likely, "please convert to image/png at 320x240" which may or=20 >>> may not involve size or format conversion. >>>=20 >>> -- >>> Sent from my wireless e-mail device. Sorry if terse. We all need >>> lemonade: see =20 >for what=20 >>> lemonade is. >>>=20 >>> -----Original Message----- >>> From: Zoltan.Ordogh@nokia.com >>> To: Eric Burger; lemonade@ietf.org >>> Sent: Mon Jun 25 01:35:44 2007 >>> Subject: RE: [lemonade] CONVERT - Clients Do Not Know >>>=20 >>> Hi Eric, >>>=20 >>>> I would like to ask a sanity check question: who REALLY is=20 >going to=20 >>>> offer the user the option of which converted-to format to >>> download? My >>>> assertion is most of the time the device will decide for the user,=20 >>>> i.e., "file is in image/foo, I only understand image/png,=20 >so please=20 >>>> convert," or, "image is 1960x1400 at 16-bit depth, I can=20 >only render=20 >>>> 320x240 at 8-bit depth, so please convert." >>>=20 >>> Do You mean format, size or both? >>>=20 >>> Notice: This email message, together with any attachments, may=20 >>> contain information of BEA Systems, Inc., its subsidiaries and=20 >>> affiliated entities, that may be confidential, proprietary,=20 >>> copyrighted and/or legally privileged, and is intended solely for=20 >>> the use of the individual or entity named in this message.=20 >If you are=20 >>> not the intended recipient, and have received this message=20 >in error,=20 >>> please immediately return this by email and then delete it. >>>=20 >>=20 > > > >Notice: This email message, together with any attachments,=20 >may contain information of BEA Systems, Inc., its=20 >subsidiaries and affiliated entities, that may be=20 >confidential, proprietary, copyrighted and/or legally=20 >privileged, and is intended solely for the use of the=20 >individual or entity named in this message. If you are not the=20 >intended recipient, and have received this message in error,=20 >please immediately return this by email and then delete it. > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > > >_______________________________________________ >lemonade mailing list >lemonade@ietf.org >https://www1.ietf.org/mailman/listinfo/lemonade >Supplemental Web Site: >http://www.standardstrack.com/ietf/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 29 07:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EyL-0005aG-DB; Fri, 29 Jun 2007 07:49:09 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I4EyK-0005aA-KU for lemonade-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 07:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4EyK-0005a2-Av for lemonade@ietf.org; Fri, 29 Jun 2007 07:49:08 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Ey1-00019v-Qr for lemonade@ietf.org; Fri, 29 Jun 2007 07:49:08 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 29 Jun 2007 12:48:48 +0100 Message-ID: <4684F147.4080409@isode.com> Date: Fri, 29 Jun 2007 12:47:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Burger Subject: Re: [lemonade] CONVERT - Clients Do Not Know References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Eric Burger wrote: >Thoughts on the idea of maximum size (or suggested size) as the parameter, >rather than format? > > I like this approach and I think it addresses Greg's issue. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 29 09:35:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Gcm-00019T-Qe; Fri, 29 Jun 2007 09:35:00 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I4Gck-00018O-Nd for lemonade-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 09:34:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Gck-00015w-CE for lemonade@ietf.org; Fri, 29 Jun 2007 09:34:58 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Gcj-0003CR-Sx for lemonade@ietf.org; Fri, 29 Jun 2007 09:34:58 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5TDX9dg024488; Fri, 29 Jun 2007 08:33:25 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 08:33:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Future Release in LEMONADE Profile bis? Date: Fri, 29 Jun 2007 08:33:22 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19E65FBB@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Future Release in LEMONADE Profile bis? Thread-Index: AceXdbM+K2vvzBq+QJ6KRE2Xq0stmggvX+cwAGQn/W4AIpCckA== From: "Vaudreuil, Greg M \(Greg\)" To: "Eric Burger" X-OriginalArrivalTime: 29 Jun 2007 13:33:22.0655 (UTC) FILETIME=[10476EF0:01C7BA52] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Well.... the point of lemonade was to create a profile with a new minimum-to-implement set of features that client could assume. The idea as I understood it was a client could get "skinny" by assuming either base IMAP or LEMONADE IMAP. By having two distinct levels of functionality, one could simplify both the user experience and the code by eliminating or significantly reducing expensive "options". The cost of not doing so is that this is one more "option" that may or may not be present. Most annoyingly, the presence of this option can be known at composition time only by more icky client configuration or a client caching the capabilities of the submission server from the last connect. If this is the model, I'd like to include Future Release in that higher functional tier. Greg V. -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Thursday, June 28, 2007 4:35 PM To: Vaudreuil, Greg M (Greg) Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] Future Release in LEMONADE Profile bis? I don't see it that way, unless one is creating a "Lemonade client" that does not follow standard IMAP and assumes features are there, and thus Future Delivery, if not in the Profile, is clearly a weird thing. If one creates clients that happen to implement lemonade, and they want to do future delivery, they just do future delivery. What could possibly go wrong? On 6/26/07 1:53 PM, "Vaudreuil, Greg M (Greg)" wrote: >=20 > I reviewed the minutes and list, but don't see clearly if we agreed that > future-release was to be included in the Ph-2 LEMONADE profile. There > was plenty of debate as to whether the extension should be worked as a > formal WG item or not, with a flip-flop-flip in the history. That > document is now done, RFC 4865. >=20 > I'd like to suggest that future-release is included in Profile-BIS. It > is a simple extension with high utility to a diverse client, especially > with intermittent connectivity or subject to unforseen battery > exhaustion. In general, fewer options are better than more, and this is > an extension I expect to be widely implemented regardless of whether it > is in LEMONADE or not. Not including simply requires supporting another > code-path in the client and another diverse user experience :-( >=20 > Greg V. >=20 >=20 >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Fri Jun 29 09:35:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Gcx-0001Yn-06; Fri, 29 Jun 2007 09:35:11 -0400 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1I4Gcw-0001Yh-ME for lemonade-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 09:35:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Gcw-0001YZ-BL for lemonade@ietf.org; Fri, 29 Jun 2007 09:35:10 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Gcv-0003Bm-Sz for lemonade@ietf.org; Fri, 29 Jun 2007 09:35:10 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5TDXMOr024677; Fri, 29 Jun 2007 08:33:22 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 08:33:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] CONVERT - Clients Do Not Know Date: Fri, 29 Jun 2007 08:33:22 -0500 Message-ID: <89017B166CB7E140BA80577FF744AE19E65FBA@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] CONVERT - Clients Do Not Know Thread-Index: Ace2knGOsDBJCSKFEdyIygAWy4mm/wAcQ5WAABvTmfoAGf4Z8AB6LsWYACJ321A= From: "Vaudreuil, Greg M \(Greg\)" To: "Eric Burger" , X-OriginalArrivalTime: 29 Jun 2007 13:33:22.0484 (UTC) FILETIME=[102D5740:01C7BA52] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org In private email, Alexy has encouraged me to drop my objections to using = actual size, and to defer until later any extension to provide = inexpensive hints as to the possibly converted objects size. I believe = the need is not well enough understood to delay this valuable body of = work. In particular, I've been convinced that most conversions will be chosen = based on application context without regard to size. That is, if you = want a thumbnail preview, you ask for a preview. If you need to use AMR = audio, you ask for AMR. There are cases where it would be useful to = have more information to choose between alternatives, trading fidelity = for size, but as this thread has shown, it is not clear at this time = what information is needed to make these trade-offs. Lets move on. Greg V. -----Original Message----- From: Eric Burger [mailto:eburger@bea.com] Sent: Thursday, June 28, 2007 4:33 PM To: lemonade@ietf.org Subject: Re: [lemonade] CONVERT - Clients Do Not Know Thoughts on the idea of maximum size (or suggested size) as the = parameter, rather than format? On 6/26/07 3:21 AM, "Zoltan.Ordogh@nokia.com" wrote: > Or, > "please convert to image/png or image/jpg but no more than = 1megabytes"? > (server decides image resolution) > "please convert to 320x240 but no more than 10kilobytes"? (server = decides a > format based on info about client and suitable compression that = provides <10k) >=20 > I think mobile devices are more likely to convert due to attachment = size limit > than convert due to image resolution/format. >=20 > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 >=20 >=20 >=20 >> -----Original Message----- >> From: ext Eric Burger [mailto:eburger@bea.com] >> Sent: 26 June, 2007 00:50 >> To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); lemonade@ietf.org >> Subject: Re: [lemonade] CONVERT - Clients Do Not Know >>=20 >> Most likely, "please convert to image/png at 320x240" which >> may or may not involve size or format conversion. >>=20 >> -- >> Sent from my wireless e-mail device. Sorry if terse. We all >> need lemonade: see >> for what lemonade is. >>=20 >> -----Original Message----- >> From: Zoltan.Ordogh@nokia.com >> To: Eric Burger; lemonade@ietf.org >> Sent: Mon Jun 25 01:35:44 2007 >> Subject: RE: [lemonade] CONVERT - Clients Do Not Know >>=20 >> Hi Eric, >>=20 >>> I would like to ask a sanity check question: who REALLY is going to >>> offer the user the option of which converted-to format to >> download? My >>> assertion is most of the time the device will decide for the user, >>> i.e., "file is in image/foo, I only understand image/png, so please >>> convert," or, "image is 1960x1400 at 16-bit depth, I can only render >>> 320x240 at 8-bit depth, so please convert." >>=20 >> Do You mean format, size or both? >>=20 >> Notice: This email message, together with any attachments, >> may contain information of BEA Systems, Inc., its >> subsidiaries and affiliated entities, that may be >> confidential, proprietary, copyrighted and/or legally >> privileged, and is intended solely for the use of the >> individual or entity named in this message. If you are not the >> intended recipient, and have received this message in error, >> please immediately return this by email and then delete it. >>=20 >=20 Notice: This email message, together with any attachments, may contain = information of BEA Systems, Inc., its subsidiaries and affiliated = entities, that may be confidential, proprietary, copyrighted and/or = legally privileged, and is intended solely for the use of the individual = or entity named in this message. If you are not the intended recipient, = and have received this message in error, please immediately return this = by email and then delete it. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade