From lemonade-bounces@ietf.org Tue Jan 08 08:12:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEFf-00088J-9m; Tue, 08 Jan 2008 08:12:19 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JCEFe-00088C-2E for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 08:12:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEFd-000884-Ny for lemonade@ietf.org; Tue, 08 Jan 2008 08:12:17 -0500 Received: from mgw-fb01.nokia.com ([192.100.122.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCEFb-00082R-IC for lemonade@ietf.org; Tue, 08 Jan 2008 08:12:17 -0500 Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m08DCChK029250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Jan 2008 15:12:13 +0200 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m08DBSis030199; Tue, 8 Jan 2008 15:11:47 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 15:11:12 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 15:11:12 +0200 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] WGLC CONVERT Date: Tue, 8 Jan 2008 15:11:13 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] WGLC CONVERT Thread-Index: AchBvzyFey6Gvq2yEdyzqwAWy4mm/wQKxaZA References: From: "Zoltan.Ordogh@nokia.com" To: , X-OriginalArrivalTime: 08 Jan 2008 13:11:12.0239 (UTC) FILETIME=[F103CFF0:01C851F7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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 all, I have reviewed this draft several times earlier, so this time I have = only a few, since most of my comments are editorial. Great job Alexey, thank You! Comments: 1. ToC: page numbers are missing (editorial). 2. 4.2, par 5: typo in "MUST use the lowercases version" 3. 4.2, par 10(?): word change suggestion 'option'->'optional' in = "supports the following types of option parameters" 4. 4.2, par 11: "As with conversion types, some "wildcarding" is = permitted." 'some "wildcarding' sounds quite vague - can we specify = 'some' exactly (to avoid misinterpretations)? 5. 5., third last par.: typo in "The server ought to endeavour to = preserver" 6. 5., third last par.: wording change suggestion. Original: "But in a case like this, where characters are split (legally!) between = fragments of an encoded parameter what is the server to do? A safe = answer is to consolidate parameters that are in pieces, convert them and = emit them fragmenting them again if necessary to keep the line length = less than 78." Proposal: "In case the characters are split (legally!) between fragments of an = encoded parameter, the server MUST consolidate the parameter fragments, = and convert, emit and re-fragment them as necessary in order to keep the = line length less than 78." 7. 5., third last par.: remove extra 'to' in "Comments embedded like = this can be moved to after the parameter:" 8. 5. last sentence: wording change suggestion. Original: "It is important the encoded words be left as encoded words as to do = otherwise may alter the semantics of structured headers." Proposal: "The encoded words MUST remain encoded, otherwise the semantics of = structured headers might be inadvertently altered." 9. 6. par 1: typo in "minally" -> "minimally" 10. 6. par 2: wording change suggestion. Original: "Note, a server implementation is not required to implement any = conversion from the text MIME subtypes specified above, except for the = mandatory to implement conversion described in section 6.1." Proposal: Original: "Note, a server implementation is not required to support any conversion = from the text MIME subtypes specified above, except for the mandatory = transcoding parameters described in section 6.1." 11. 6. par 3 and example under it. Should PIX-X, PIX-Y and IMAGE/JPG be = lowercase? (See case sensitivity in Section 5). 12. 6.1 title: suggest change. Original: "Mandatory Transcoding support" Proposal: "Mandatory Transcoding parameters" 13. 6.1 par 4: does this belong here? This section is about mandatory = things, not SHOULDs. 14. 6.2 title: suggest change. Original: "Additional features for mobile usage" Proposal: "Additional Transcoding parameters for mobile usage" 15. 7.3 par 2: wording change suggestion. Original: Clients MUST NOT remember sizes of converterted messages/ body parts across multiple IMAP "sessions". (This requirement allows an server implementation to upgrade its transcoding component without breaking interoperability.) Proposal: "In order to guarantee safe upgrade of server transcoding components, = clients MUST NOT assume that repeating a particular bodypart conversion = yields the same result as a previous conversion of the very same = bodypart - any characteristics of a bodypart might be different (format, = size, etc)." 16. 12.2 [MEMAIL] The draft has expired long ago - do we keep this? = (referenced only once in Section 1.) 17. General In section one, we read this: "Conversion (adaptation,=20 transcoding) may be requested by the client and performed by the=20 server on a best effort basis or, when requested by the client, decided by the server based on server's=20 knowledge of the client capabilities, user or administrator=20 preferences or server settings." best effort -> clear client capabilities -> not in the scope administrator preferences -> not in the scope server settings -> not in the scope What about user preferences? I think that this is something that is in = the scope since the user will store His/Her preferences on the server. = Should this be described somehow? Thank you. 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: 18 December, 2007 23:45 >To: lemonade@ietf.org >Subject: [lemonade] WGLC CONVERT > >The work group last call for CONVERT ends 8 January 2008. =20 >Please have at it. > >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-13.txt > > >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 From lemonade-bounces@ietf.org Tue Jan 08 08:47:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEnF-0002EV-Fy; Tue, 08 Jan 2008 08:47:01 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JCEnE-0002EO-D3 for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 08:47:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEnE-0002DV-2j for lemonade@ietf.org; Tue, 08 Jan 2008 08:47:00 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCEnB-0000dX-Vn for lemonade@ietf.org; Tue, 08 Jan 2008 08:47:00 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m08DkrZC018834; Tue, 8 Jan 2008 07:47:34 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 15:46:39 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 15:46:39 +0200 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] Include draft-melnikov-imapext-filters into LemonadeProfile Bis? Date: Tue, 8 Jan 2008 15:46:41 +0200 Message-ID: In-Reply-To: <47696D10.5080302@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] Include draft-melnikov-imapext-filters into LemonadeProfile Bis? Thread-Index: AchCdZ2YGImFCVU0SPGCuISMN2TLcAPhxUiQ References: <1792079180.22741198091171861.JavaMail.root@dogfood.zimbra.com> <47696D10.5080302@isode.com> From: To: , X-OriginalArrivalTime: 08 Jan 2008 13:46:39.0449 (UTC) FILETIME=[E4EE4C90:01C851FC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Alexey and all, I would like to see this draft (draft-melnikov-imapext-filters-xx) as = part of Lemonade as well. 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: 19 December, 2007 21:12 >To: Dan Karp >Cc: Lemonade WG >Subject: [lemonade] Include draft-melnikov-imapext-filters=20 >into LemonadeProfile Bis? > >Dan Karp wrote: > >>>>I almost agree with you. Almost, because support for=20 >virtual views is=20 >>>>missing one small piece, which is storing search filters on IMAP=20 >>>>server (draft-melnikov-imapext-filters-02.txt). This piece=20 >currently=20 >>>>depends on per-user METADATA. >>>> =20 >>>> >>>Which it shouldn't. >>> =20 >>> >>+1 >> =20 >> >Am I correct in interpreting that as: >1). People would like to make draft-melnikov-imapext-filters=20 >independent of METADATA (so that it can be used with METADATA,=20 >ACAP, LDAP, XCAP, >whatever) >2). People would like to include=20 >draft-melnikov-imapext-filters (after it is updated as=20 >described in 1) into Profile Bis, because they agree it is a=20 >missing piece? > > > >_______________________________________________ >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 Jan 08 08:54:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEur-00073g-G3; Tue, 08 Jan 2008 08:54:53 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JCEup-00073X-TF for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 08:54:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCEup-00073P-Je for lemonade@ietf.org; Tue, 08 Jan 2008 08:54:51 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCEup-0000n5-8p for lemonade@ietf.org; Tue, 08 Jan 2008 08:54:51 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m08DsgZw025553; Tue, 8 Jan 2008 07:55:35 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 15:54:27 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Jan 2008 15:54:27 +0200 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] Mail Organization Date: Tue, 8 Jan 2008 15:54:28 +0200 Message-ID: In-Reply-To: <11509.1197720203.881872@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] Mail Organization Thread-Index: Acg/EofsP7ltcZf6Ssyj+eXaNISPrgS6rAQw References: <7ff232d10712141532h41c06474s575c3d37b28494f@mail.gmail.com> <11509.1197720203.881872@peirce.dave.cridland.net> From: To: , X-OriginalArrivalTime: 08 Jan 2008 13:54:27.0298 (UTC) FILETIME=[FBCA6420:01C851FD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Dave, >-----Original Message----- >From: ext Dave Cridland [mailto:dave@cridland.net]=20 >Sent: 15 December, 2007 14:03 >To: Enhancements to Internet email to support diverse service=20 >enivronments >Subject: Re: [lemonade] Mail Organization > >It's largely out of scope for Lemonade - I say largely,=20 >because information overload on a mobile phone is=20 >substantially worse than for a desktop, and so Lemonade has=20 >developed techniques for filtering mail - CONTEXT, WITHIN, etc. There is a debate going on (still trying to catch up with my backlog after my vacation) about WITHIN - might be removed from bis... That would leave only one technique to filter mails... _______________________________________________ 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 Jan 08 11:15:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCH76-0003cH-AR; Tue, 08 Jan 2008 11:15:40 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JCH70-0003OH-O4 for lemonade-confirm+ok@megatron.ietf.org; Tue, 08 Jan 2008 11:15:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCH70-0003Nz-Cv; Tue, 08 Jan 2008 11:15:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCH70-00075l-0B; Tue, 08 Jan 2008 11:15:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9C4C3175CF; Tue, 8 Jan 2008 16:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JCH6V-0006Vp-3w; Tue, 08 Jan 2008 11:15:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Jan 2008 11:15:03 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-notifications-06.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 : Lemonade Notifications Architecture Author(s) : R. Gellens Filename : draft-ietf-lemonade-notifications-06.txt Pages : 16 Date : 2008-1-8 This document discusses how to provide notification and filtering mechanisms to IMAP to meet Lemonade goals. This document also discusses the use of server to server notifications, and how server to server notifications fit into an architecture which provides server to client notifications. Gellens [page 1] Expires May 2008 Internet Draft Lemonade Notifications and Filters November 2007 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-06.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-notifications-06.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-notifications-06.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: <2008-1-8103339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-notifications-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-notifications-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-8103339.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 Wed Jan 09 17:20:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjHI-0007Dk-Lk; Wed, 09 Jan 2008 17:20:04 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JCjHG-0007DW-MZ for lemonade-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 17:20:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjHG-0007DO-CL; Wed, 09 Jan 2008 17:20:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCjHG-0003Lf-0H; Wed, 09 Jan 2008 17:20:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id F05643287E; Wed, 9 Jan 2008 22:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JCjHF-0001kh-St; Wed, 09 Jan 2008 17:20:01 -0500 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, 09 Jan 2008 17:20:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: lemonade@ietf.org Subject: [lemonade] I-D Action:draft-ietf-lemonade-msgevent-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 : Internet Message Store Events Author(s) : R. Gellens, C. Newman Filename : draft-ietf-lemonade-msgevent-05.txt Pages : 20 Date : 2008-01-09 One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-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-msgevent-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-msgevent-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: <2008-01-09171448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-msgevent-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-msgevent-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-09171448.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 Fri Jan 11 09:33:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKwR-0007GO-Jz; Fri, 11 Jan 2008 09:33:03 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JDKwQ-0007GD-LG for lemonade-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 09:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKwQ-0007G5-BT for lemonade@ietf.org; Fri, 11 Jan 2008 09:33:02 -0500 Received: from mail.freax.org ([86.39.154.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDKwO-000613-1s for lemonade@ietf.org; Fri, 11 Jan 2008 09:33:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id E537FEC856; Fri, 11 Jan 2008 15:24:22 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNJMKu52PdIU; Fri, 11 Jan 2008 15:24:22 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 9D202EC7E5; Fri, 11 Jan 2008 15:24:22 +0100 (CET) From: Philip Van Hoof To: lemonade@ietf.org Content-Type: text/plain Date: Fri, 11 Jan 2008 15:32:45 +0100 Message-Id: <1200061965.8451.30.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Alexey Melnikov Subject: [lemonade] CONVERT 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 o. In CONVERT's 13th draft: Instead of specifying the exact target MIME media type the client wants to convert to, the client MAY use a special marker NIL (also known as "default conversion") to request the server to pick a suitable target media type. This document doesn't describe how the server makes such a choice. etc etc An E-mail client must prepare its mime part view so that it can show the content of what is being received efficiently. With a default MIME media type that will be used to convert to, this ain't possible. For example a thumbnail of a streaming video, converting to a progressive JPEG, etc. Therefore are all concepts of the server providing some sort of a default conversion target not useful for an E-mail client. o. The concept of having a registry of possible conversions using GETMETADATA can't support conversions of one of the most common MIME part types: application/octet-stream. What the client developer really wants is once he received and parsed the bodystructure and figured that it can't use a MIME part, to ask the IMAP server what it can convert "that specific" MIME part to. For example in case the bodystructure said: application/octet-stream, the IMAP server could tell the E-mail client: but I can convert it to a resized flash animation for you, or a video/mpeg, ... This ain't possible with GETMETADATA, as GETMETADATA can't support application/octet-stream, because it can't tell the client what "that specific" MIME part is about. So the client has no clue either. I fear that a registry of possible conversions, like GETMETADATA, is therefore wrong. I think the list of possible conversions should be queryable per specific MIME part. - The client can then "see" a application/octet-stream and ask the IMAP server whether it can offer the data in a better format - The server can at that point perform a slow operation to figure out the content of that MIME part, to compute its list of conversion formats, and return it to the client. I know IMAP server developers think this is a burden for them to implement, but the client really has no clue whatsoever what the data is about. So it can't know what it could possibly ask for when requesting a CONVERT. (note that this procedure does not need to be fast, if the imap server has to scan the header of the data and it consumes time doing that, that's fine, really) - The client can now prepare itself for the retrieval of this data in a for itself useful formatting - The client can now request the CONVERT, and keep its viewer/retriever ready for the data - The IMAP server sends the converted data to the client, the client's viewer/retriever shows it to the user This is not possible with GETMETADATA: - Only known MIME parts can be supported. The application/octet-data MIME part can't be supported (this just doesn't fit in the concept of a registry of possible conversions, as each application/octet-data can be different. And the client doesn't know anything whatsoever about the format of that data, at that point). Note that application/octet-data is the most likely format that will have to be converted. It's precisely for that kind of MIME parts that convert is interesting. - Else NIL must be used which means that the client has no idea whatsoever that will be sent -> It must parse the BODYPARTSTRUCTURE CONVERT response and immediately after that must it be prepared for that: - What if it nonetheless can't support that default format?! Must it receive useless data and waste bandwidth now?! - What if the CPU of the device just isn't fast enough to prepare a mime part viewer quickly enough to start showing the now converted data, that is already being received, to the user? Short version, CONVERT's draft 13 is not implementable for a client in a convenient way. The methodology of a registry of possible conversions, doesn't really work ... The idea of a default conversion absolutely doesn't work for the client. It's a conversion that goes like: C: I have no clue, give me something ... something whatever S: I'm going to send you some stuff, a millisecond before I send you the data I'll tell you how it'll look, but I wont tell you what I will send you until that millisecond before I start. If that data doesn't work for you, all you can do is cut the connection or politely waste bandwidth until I'm finished sending. Doesn't make sense imho ... In stead of C: I have no clue, give me A CLUE S: A clue: I can do A B and C C: Alright, so give me B -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ 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 Jan 11 09:40:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDL3C-0007Wt-O7; Fri, 11 Jan 2008 09:40:02 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JDL3B-0007Th-Rf for lemonade-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 09:40:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDL3B-0007SG-GH for lemonade@ietf.org; Fri, 11 Jan 2008 09:40:01 -0500 Received: from mail.freax.org ([86.39.154.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDL3A-00065m-2u for lemonade@ietf.org; Fri, 11 Jan 2008 09:40:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id BE0F1EC87A; Fri, 11 Jan 2008 15:31:27 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IawY3xBMWWra; Fri, 11 Jan 2008 15:31:27 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id 71841EC856; Fri, 11 Jan 2008 15:31:27 +0100 (CET) Subject: Re: [lemonade] CONVERT From: Philip Van Hoof To: lemonade@ietf.org In-Reply-To: <1200061965.8451.30.camel@schtrumpf> References: <1200061965.8451.30.camel@schtrumpf> Content-Type: text/plain Date: Fri, 11 Jan 2008 15:39:50 +0100 Message-Id: <1200062390.8451.32.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 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 Fri, 2008-01-11 at 15:32 +0100, Philip Van Hoof wrote: > In stead of > > C: I have no clue, give me A CLUE > > S: A clue: I can do A B and C > > C: Alright, so give me B Note that GETMETADATA would be useful to save a roundtrip asking for the clue in case the client actually has a clue. But the only way it can have a clue, is by recognising a known MIME part that was registered in the GETMETADATA registry. Which wont be the case for application/octet-stream, for example. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ 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 Jan 14 05:47:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEMqM-000279-Im; Mon, 14 Jan 2008 05:47:02 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JEMqL-00026y-A0 for lemonade-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 05:47:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEMqK-00026q-T0 for lemonade@ietf.org; Mon, 14 Jan 2008 05:47:01 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEMqJ-0000Vz-6f for lemonade@ietf.org; Mon, 14 Jan 2008 05:47:00 -0500 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, 14 Jan 2008 10:46:57 +0000 Message-ID: <478B3D82.2060506@isode.com> Date: Mon, 14 Jan 2008 10:46:26 +0000 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 MIME-Version: 1.0 To: Lemonade WG Content-Type: multipart/mixed; boundary="------------030605020308070800050004" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [lemonade] [Fwd: Last Call: draft-daboo-imap-annotatemore (IMAP METADATA Extension) to Proposed Standard] 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 --------------030605020308070800050004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please review the latest version of the document and please don't get distracted by the discussion about inclusion of this document in Lemonade Profile Bis. --------------030605020308070800050004 Content-Type: message/rfc822; name="Last Call: draft-daboo-imap-annotatemore (IMAP METADATA Extension) to ProposedStandard" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Last Call: draft-daboo-imap-annotatemore (IMAP METADATA Extension) to ProposedStandard" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.1v1) with LMTP; Wed, 02 Jan 2008 15:01:53 +0000 (GMT) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Wed, 2 Jan 2008 15:01:44 +0000 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA54C-0008En-Kl; Wed, 02 Jan 2008 09:59:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA54A-00088O-FL for ietf-announce@ietf.org; Wed, 02 Jan 2008 09:59:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA54A-0003Ej-86 for ietf-announce@ietf.org; Wed, 02 Jan 2008 09:59:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 38B7F328CF for ; Wed, 2 Jan 2008 14:59:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JA53g-0002GL-48 for ietf-announce@ietf.org; Wed, 02 Jan 2008 09:59:04 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 02 Jan 2008 09:59:04 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: Last Call: draft-daboo-imap-annotatemore (IMAP METADATA Extension) to Proposed Standard X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'IMAP METADATA Extension ' 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 2008-01-30. 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-daboo-imap-annotatemore-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8469&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------030605020308070800050004 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 --------------030605020308070800050004-- From lemonade-bounces@ietf.org Tue Jan 15 12:29:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpav-0005z1-EY; Tue, 15 Jan 2008 12:29:01 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JEpat-0005yr-Ld for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 12:28:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEpat-0005yg-9w for lemonade@ietf.org; Tue, 15 Jan 2008 12:28:59 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEpas-00011c-Sz for lemonade@ietf.org; Tue, 15 Jan 2008 12:28:59 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0FHSuQ15669 for ; Tue, 15 Jan 2008 17:28:56 GMT 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, 15 Jan 2008 12:28:57 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D133C1277@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for interop proposals Thread-Index: AchT7Gy4heR3sYa6Tvi77TxVya3r+gDrn/Rw From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [lemonade] FW: Call for interop proposals 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 Folks, There is a proposal for an IETF Apps Area interop event at IETF 71. This is the first time such an event has been proposed -- see below. Given that we recently held a LEMONADE interop in November, is anyone interested in another one in March? And if anyone is interested, we would need a volunteer to organize this. Cheers, Glenn.=20 -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@commerce.net]=20 Sent: Wednesday, January 09, 2008 8:13 PM To: Apps Discuss Subject: Call for interop proposals At the Apps area open meeting in Vancouver, Chris & I mentioned the possibility of doing a day of interoperability events at the next IETF meeting. This would replace a day of Apps area meetings during the normal meeting hours and in the normal meeting location. Ideally it would allow people to come to the IETF for more than just "their" =20 meeting (although we have always hoped they can attend other WG meetings as well) and participants may get more benefit and better justification for attending. If we're going to do this, we need proposals: what topic ( IDs, RFCs, suites or functionality) will be tested. I don't think interops will need a lot of management but volunteer coordinators would be ideal. Proposals will need to be followed quickly by some indications of who will participate. WG scheduling is already open and we need to tell the Secretariat immediately if they need to reserve a day for interops. Proposals should probably be posted on some relevant subject mailing list to quickly generate discussion among potential participants -- not everybody reads Apps Discuss. Thanks, Lisa _______________________________________________ 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 Jan 15 14:13:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JErDw-0002BU-Ov; Tue, 15 Jan 2008 14:13:24 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JErDu-0002BP-S2 for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 14:13:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JErDu-0002BG-I2 for lemonade@ietf.org; Tue, 15 Jan 2008 14:13:22 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JErDs-0003Th-7t for lemonade@ietf.org; Tue, 15 Jan 2008 14:13:22 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 15 Jan 2008 19:13:18 +0000 Message-ID: <478D0590.9070800@isode.com> Date: Tue, 15 Jan 2008 19:12:16 +0000 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 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: 769a46790fb42fbb0b0cc700c82f7081 Cc: IMAP Extensions WG Subject: [lemonade] Re: Last Call: draft-gulbrandsen-imap-enable (The IMAP ENABLE Extension) to Proposed Standard 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 wrote: >The IESG has received a request from an individual submitter to consider >the following document: > >- 'The IMAP ENABLE Extension ' > 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 2008-01-16. 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-gulbrandsen-imap-enable-05.txt > > So far I've only seen one minor comment from a Gen-Art reviewer who spotted that RFC 2177 is no longer referenced. If you have more substantial comments, please send them before tomorrow. One possible change to ENABLE was suggested by Cyrus on the mailing list when discussing CONVERT capability discovery, see A possible solution for this would be to change the ENABLE command to allow arbitrary parameters to capabilities enclosed in (), e.g. tag1 ENABLE CONVERT (("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED" "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE" ("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320")) Servers would be required to ignore parameters for capabilities they don't understand. My personal opinion about this change: While I don't feel strongly against this change I am not convinced that it is needed. Besides, the way ENABLE is defined, we can get away without it. Multiple ENABLE commands are additive. A client can send each capability with parameters in a separate ENABLE command, as shown above. A server that doesn't recognize this would reject such ENABLE with BAD. Thoughts? 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 Tue Jan 15 15:37:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsXQ-0006ij-7u; Tue, 15 Jan 2008 15:37:36 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JEsXO-0006cw-Fc for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:37:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsXO-0006Jp-3P for lemonade@ietf.org; Tue, 15 Jan 2008 15:37:34 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEsXL-0005eW-Ek for lemonade@ietf.org; Tue, 15 Jan 2008 15:37:31 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ACA5B4AC59; Tue, 15 Jan 2008 21:37:29 +0100 (CET) Message-Id: Date: Tue, 15 Jan 2008 21:37:29 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org References: <478D0590.9070800@isode.com> In-Reply-To: <478D0590.9070800@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Alexey Melnikov Subject: [lemonade] Re: Last Call: draft-gulbrandsen-imap-enable (The IMAP ENABLE Extension) to Proposed Standard 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 writes: > One possible change to ENABLE was suggested by Cyrus on the mailing > list when discussing CONVERT capability discovery, see > > > A possible solution for this would be to change the ENABLE command to > allow arbitrary parameters to capabilities enclosed in (), e.g. > > tag1 ENABLE CONVERT (("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" > ("FLOWED" "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) > ("IMAGE" ("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320")) > > Servers would be required to ignore parameters for capabilities they > don't understand. ENABLE so far has been about enabling server-side behaviour by explicit command instead of as a side effect of another command. This change would add a general parameter facility for IMAP extensions. Instead of just being on/off, IMAP extensions would now have complex paramaters. I have two comments on that. 1. Most importantly, adding something that big one day before the end of IETF LC is really bad. I might even raise an appeal to prevent that, to make sure we get proper discussion and a new last call. It's unfair on reviewers to more than double the complexity of an extension one day before the end of IETF LC. 2. Less importantly, I'm not sure it's called for. We have only one use case, and it's not even an awfully strong use case. (Should I make an alternative suggestion for CONVERT? Not in this thread.) 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 Tue Jan 15 15:49:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsjM-0007UE-GY; Tue, 15 Jan 2008 15:49:56 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JEsjL-0007U9-70 for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:49:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsjK-0007U1-S0 for lemonade@ietf.org; Tue, 15 Jan 2008 15:49:54 -0500 Received: from dsl-217-155-137-60.zen.co.uk ([217.155.137.60] helo=turner.dave.cridland.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEsjK-0005wr-6I for lemonade@ietf.org; Tue, 15 Jan 2008 15:49:54 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 15 Jan 2008 20:49:25 +0000 Subject: Re: [lemonade] Re: Last Call: draft-gulbrandsen-imap-enable (The IMAP ENABLE Extension) to Proposed Standard References: <478D0590.9070800@isode.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <17077.1200430164.817191@peirce.dave.cridland.net> Date: Tue, 15 Jan 2008 20:49:24 +0000 From: Dave Cridland To: Mark Crispin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Enhancements to Internet email to support diverse service enivronments , ietf-imapext@imc.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 Tue Jan 15 20:40:06 2008, Mark Crispin wrote: > > +1 > > I'm in broad agreement. > On Tue, 15 Jan 2008, Arnt Gulbrandsen wrote: >> Alexey Melnikov writes: >>> One possible change to ENABLE was suggested by Cyrus on the >>> mailing list when discussing CONVERT capability discovery, see >>> >>> >>> A possible solution for this would be to change the ENABLE >>> command to allow arbitrary parameters to capabilities enclosed in >>> (), e.g. >>> >>> tag1 ENABLE CONVERT (("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" >>> ("FLOWED" "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) >>> ("IMAGE" ("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320")) >>> >>> Servers would be required to ignore parameters for capabilities >>> they don't understand. >> >> ENABLE so far has been about enabling server-side behaviour by >> explicit command instead of as a side effect of another command. >> >> This change would add a general parameter facility for IMAP >> extensions. Instead of just being on/off, IMAP extensions would >> now have complex paramaters. >> >> I have two comments on that. >> >> 1. Most importantly, adding something that big one day before the >> end of IETF LC is really bad. I might even raise an appeal to >> prevent that, to make sure we get proper discussion and a new last >> call. It's unfair on reviewers to more than double the complexity >> of an extension one day before the end of IETF LC. >> >> +1 on this argument, and I think this argument is sufficient. >> 2. Less importantly, I'm not sure it's called for. We have only >> one use case, and it's not even an awfully strong use case. >> (Should I make an alternative suggestion for CONVERT? Not in this >> thread.) I'm not convinced that a generic mechanism is called for. Architecting such a mechanism is not going to be trivial, especially with only one sketched out use-case. Especially when I've got my own concerns with whether my own proposal satisfies the requirements of client developers as well as it should. FWIW, I'm happy with ENABLE as-is. 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 Tue Jan 15 15:55:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsoy-000073-Do; Tue, 15 Jan 2008 15:55:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JEsow-00006k-Mv for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:55:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsow-00006X-C0 for lemonade@ietf.org; Tue, 15 Jan 2008 15:55:42 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEsov-00065A-UP for lemonade@ietf.org; Tue, 15 Jan 2008 15:55:42 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id F084F4AC72; Tue, 15 Jan 2008 21:55:40 +0100 (CET) Message-Id: Date: Tue, 15 Jan 2008 21:55:40 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: Last Call: draft-gulbrandsen-imap-enable (The IMAP ENABLE Extension) to Proposed Standard References: <478D0590.9070800@isode.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Cc: 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 Huh. On rereading, the tone of that missive is a leeetle stronger than I intended. Sorry about that. _______________________________________________ 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 Jan 16 05:26:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5TK-00029f-71; Wed, 16 Jan 2008 05:26:14 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JF5TJ-00027B-Cn for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 05:26:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF5TI-0001zy-Bk for lemonade@ietf.org; Wed, 16 Jan 2008 05:26:12 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF5TF-0001u8-H6 for lemonade@ietf.org; Wed, 16 Jan 2008 05:26:12 -0500 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, 16 Jan 2008 10:25:55 +0000 Message-ID: <478DCC12.1060408@isode.com> Date: Wed, 16 Jan 2008 09:19:14 +0000 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 Van Hoof Subject: Re: [lemonade] CONVERT References: <1200061965.8451.30.camel@schtrumpf> In-Reply-To: <1200061965.8451.30.camel@schtrumpf> 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: 16c9da4896bf5539ae3547c6c25f06a0 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 Philip, Philip Van Hoof wrote: >o. In CONVERT's 13th draft: > > Instead of specifying the exact target MIME media type the client > wants to convert to, the client MAY use a special marker NIL (also > known as "default conversion") to request the server to pick a > suitable target media type. This document doesn't describe how the > server makes such a choice. > > etc etc > > > An E-mail client must prepare its mime part view so that it can show > the content of what is being received efficiently. With a default MIME > media type that will be used to convert to, this ain't possible. > > For example a thumbnail of a streaming video, converting to a > progressive JPEG, etc. > > Therefore are all concepts of the server providing some sort of a > default conversion target not useful for an E-mail client. > I disagree with this statement: the client can use BODYPARTSTRUCTURE to determine the target MIME type: C: e001 CONVERT 2 (NIL) (BODYPARTSTRUCTURE[2]) S: * 2 CONVERTED (TAG "e001") (BODYPARTSTRUCTURE[2] ("IMAGE" "JPG" () NIL NIL "8bit" 4182 NIL NIL NIL)) S: e001 OK UID CONVERT COMPLETED ///Now client can prepare its MIME viewer or decide not to download the part C: e002 CONVERT 2 (NIL) (BINARY[2]) S: * 2 CONVERTED (TAG "e001") (BINARY[2] ~{4182} ) S: e002 OK UID CONVERT COMPLETED >o. The concept of having a registry of possible conversions using > GETMETADATA can't support conversions of one of the most common MIME > part types: application/octet-stream. > > Philip, We had a previous iteration of this discussion off-list, but I guess my arguments were not persuasive enough. Let me try again. > What the client developer really wants is once he received and parsed > the bodystructure and figured that it can't use a MIME part, to ask > the IMAP server what it can convert "that specific" MIME part to. > > You haven't convinced me that the difference between "the server can convert ANY application/octet-stream to text/html, image/jpeg and video/foo" and "the server can convert THAT SPECIFIC application/octet-stream to text/html, image/jpeg and video/foo" is significant. If you can find a counter example, please let me know. Also see below. > For example in case the bodystructure said: application/octet-stream, > the IMAP server could tell the E-mail client: but I can convert it to > a resized flash animation for you, or a video/mpeg, ... > > This ain't possible with GETMETADATA, as GETMETADATA can't support > application/octet-stream, because it can't tell the client what "that > specific" MIME part is about. So the client has no clue either. > > GETMETADATA can list all possible target conversions for application/octet-stream. > I fear that a registry of possible conversions, like GETMETADATA, is > therefore wrong. > > I think the list of possible conversions should be queryable per > specific MIME part. > > I am not convinced, as per above. >- The client can then "see" a application/octet-stream and ask the IMAP > server whether it can offer the data in a better format > >- The server can at that point perform a slow operation to figure out > the content of that MIME part, to compute its list of conversion > formats, and return it to the client. > > I know IMAP server developers think this is a burden for them to > implement, but the client really has no clue whatsoever what the data > is about. So it can't know what it could possibly ask for when > requesting a CONVERT. > > (note that this procedure does not need to be fast, if the imap server > has to scan the header of the data and it consumes time doing that, > that's fine, really) > >- The client can now prepare itself for the retrieval of this data in a > for itself useful formatting > >- The client can now request the CONVERT, and keep its viewer/retriever > ready for the data > >- The IMAP server sends the converted data to the client, the client's > viewer/retriever shows it to the user > > >This is not possible with GETMETADATA: > >- Only known MIME parts can be supported. The application/octet-data > MIME part can't be supported (this just doesn't fit in the concept of > a registry of possible conversions, as each application/octet-data can > be different. > Well, yes. But the server can list all possible target conversions. A specific body part can be converted to a subset of such target types. >And the client doesn't know anything whatsoever about > the format of that data, at that point). > > Note that application/octet-data is the most likely format that will > have to be converted. It's precisely for that kind of MIME parts that > convert is interesting. > >- Else NIL must be used which means that the client has no idea > whatsoever that will be sent > > -> It must parse the BODYPARTSTRUCTURE CONVERT response and > immediately after that must it be prepared for that: > > - What if it nonetheless can't support that default format?! Must > it receive useless data and waste bandwidth now?! > > This would have been true without Dave Cridland's MEDIACAPS proposal. I think there is enough support for it that the CONVERT document should be updated to include it. Dave's proposal is as follows: at the beginning of an IMAP connection the client sends the server the MEDIACAPS command that lists all target MIME types supported by the client (order by client preference): t1 MEDIACAPS ("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED" "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE" ("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320") After that the server would know that a NIL conversion can only return one of the MIME types supported by the client. > - What if the CPU of the device just isn't fast enough to prepare a > mime part viewer quickly enough to start showing the now > converted data, that is already being received, to the user? > > This statement is wrong, as downloading converted data is a separate operation from determining what it was converted to. See my answer to your point # 1. >Short version, CONVERT's draft 13 is not implementable for a client in a >convenient way. The methodology of a registry of possible conversions, >doesn't really work ... > >The idea of a default conversion absolutely doesn't work for the client. > >It's a conversion that goes like: > >C: I have no clue, give me something ... something whatever > >S: I'm going to send you some stuff, a millisecond before I send you the > data I'll tell you how it'll look, but I wont tell you what I will > send you until that millisecond before I start. If that data doesn't > work for you, all you can do is cut the connection or politely waste > bandwidth until I'm finished sending. > > As I said before, this statement is not true. >Doesn't make sense imho ... > >In stead of > >C: I have no clue, give me A CLUE > >S: A clue: I can do A B and C > >C: Alright, so give me B > Taking into considerations Dave's proposal, a client-server exchange can look like this: C: I can digest B and C, I prefer B over C C: I have no clue, convert this body part to something I understand and tell me what it is S: I can convert this body part to B (The client can also discover that the server can convert this MIME type to A, B, C and D) C: Alright, so give me B _______________________________________________ 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 Jan 16 06:49:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6mF-0007U0-Vo; Wed, 16 Jan 2008 06:49:52 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JF6mE-0007L8-0F for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 06:49:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6mD-0007L0-LT for lemonade@ietf.org; Wed, 16 Jan 2008 06:49:49 -0500 Received: from mail.freax.org ([86.39.154.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF6mB-0003XM-Be for lemonade@ietf.org; Wed, 16 Jan 2008 06:49:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.freax.org (Postfix) with ESMTP id 3924FEC993; Wed, 16 Jan 2008 12:40:59 +0100 (CET) Received: from mail.freax.org ([127.0.0.1]) by localhost (mail.freax.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMV86-4jpRfU; Wed, 16 Jan 2008 12:40:58 +0100 (CET) Received: from [192.168.1.113] (d54C0EE14.access.telenet.be [84.192.238.20]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.freax.org (Postfix) with ESMTP id D6473EC9A6; Wed, 16 Jan 2008 12:40:57 +0100 (CET) Subject: Re: [lemonade] CONVERT From: Philip Van Hoof To: Alexey Melnikov In-Reply-To: <478DCC12.1060408@isode.com> References: <1200061965.8451.30.camel@schtrumpf> <478DCC12.1060408@isode.com> Content-Type: text/plain Date: Wed, 16 Jan 2008 12:49:27 +0100 Message-Id: <1200484167.8380.8.camel@schtrumpf> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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, 2008-01-16 at 09:19 +0000, Alexey Melnikov wrote: > I disagree with this statement: the client can use BODYPARTSTRUCTURE to > determine the target MIME type: > > C: e001 CONVERT 2 (NIL) (BODYPARTSTRUCTURE[2]) > S: * 2 CONVERTED (TAG "e001") (BODYPARTSTRUCTURE[2] ("IMAGE" > "JPG" () NIL NIL "8bit" 4182 NIL NIL NIL)) > S: e001 OK UID CONVERT COMPLETED > ///Now client can prepare its MIME viewer or decide not to download the part > C: e002 CONVERT 2 (NIL) (BINARY[2]) > S: * 2 CONVERTED (TAG "e001") (BINARY[2] > ~{4182} > > ) > S: e002 OK UID CONVERT COMPLETED Aha! This example I didn't first see in the specification. Since there are two separate steps, it's different from how I first interpreted it. As in your comment, indeed at that point has the client the possibility to prepare itself. Which makes that default answer more or less usable. > > - What if it nonetheless can't support that default format?! Must > > it receive useless data and waste bandwidth now?! > This would have been true without Dave Cridland's MEDIACAPS proposal. I > think there is enough support for it that the CONVERT document should be > updated to include it. Oh, I haven't seen the MEDIACAPS proposal yet. I'll soon take a look at this. > Dave's proposal is as follows: at the beginning > of an IMAP connection the client sends the server the MEDIACAPS command > that lists all target MIME types supported by the client (order by > client preference): > > t1 MEDIACAPS ("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED" > "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE" ("JPEG" > "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320") Interesting ... > After that the server would know that a NIL conversion can only return > one of the MIME types supported by the client. > > - What if the CPU of the device just isn't fast enough to prepare a > > mime part viewer quickly enough to start showing the now > > converted data, that is already being received, to the user? > > > > > This statement is wrong, as downloading converted data is a separate > operation from determining what it was converted to. > See my answer to your point # 1. Yes, I misinterpreted the spec on that point. If it are two steps, then the client can prepare itself for as long as it needs. > Taking into considerations Dave's proposal, a client-server exchange can > look like this: > > C: I can digest B and C, I prefer B over C > > > > C: I have no clue, convert this body part to something I understand and tell me what it is > > S: I can convert this body part to B > (The client can also discover that the server can convert this MIME type to A, B, C and D) > > C: Alright, so give me B Yes, and that conversation could work for the client. Thanks for the clarifications. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ 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 Jan 16 07:41:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7ab-0001vJ-H9; Wed, 16 Jan 2008 07:41:53 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JF7aa-0001vC-Iv for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 07:41:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7aa-0001v4-8f for lemonade@ietf.org; Wed, 16 Jan 2008 07:41:52 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF7aZ-0000rI-Tq for lemonade@ietf.org; Wed, 16 Jan 2008 07:41:52 -0500 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, 16 Jan 2008 12:41:50 +0000 Message-ID: <478DFB6C.1070605@isode.com> Date: Wed, 16 Jan 2008 12:41:16 +0000 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 Subject: Re: [lemonade] WGLC CONVERT 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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: >The work group last call for CONVERT ends 8 January 2008. Please have at >it. > >http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-13.txt > > The WGLC for the document has ended. There were some editorial comments from Dan and Zoltan that needs to be addressed by Peter and myself. And then there was a big discussion on discovery of available conversion. Several mechanisms were proposed, but so far I heard no consensus (please correct me if I am wrong). I will send a separate message suggesting some way to move forward on this. _______________________________________________ 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 Jan 16 08:35:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8QX-0001Lv-7Y; Wed, 16 Jan 2008 08:35:33 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JF8QW-0001Lq-B5 for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:35:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8QW-0001Lf-0R for lemonade@ietf.org; Wed, 16 Jan 2008 08:35:32 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF8QS-00027b-J7 for lemonade@ietf.org; Wed, 16 Jan 2008 08:35:29 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 543E44AC73; Wed, 16 Jan 2008 14:35:27 +0100 (CET) Message-Id: Date: Wed, 16 Jan 2008 14:35:27 +0100 From: Arnt Gulbrandsen To: Lemonade WG Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [lemonade] strawman suggestion for convert 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 All the suggestions I've seen center around providing enough flexibility to cater to whatever is needed. How about having too little flexibility instead? Solving the important 80%? I've seen basically three uses cases: 1. Convert a bodypart of some sort to a JPEG formatted for the device's screen. (Sometimes this is a sequence of JPEGs, e.g. in the case of a multipage PDF.) The bodypart may be an image, a PDF or even an animation. Often it has MIME type application/octet-stream. 2. Convert a bodypart of some sort to to an MP3, chopping it off to limited length. 3. Convert a video or audio bodypart to flash in a given resolution and stream it. Accordingly my strawman has three parts: 3. Disregard case 3 for CONVERT. We don't do streaming inside IMAP. We could "handle" it by mentioning that a streaming server can use URLAUTH/URLFETCH to obtain the bodypart. 1. Capability CONVERT=JPEG gives the ability to do 1. The client specifies JPEG, x resolution, y resolution, whether to make the result smaller or bigger if the aspect ratio is different, and a maximum number of images. The server converts to JPEG if it can, resizes, preserving aspect ratio, and sends the results. 2. Capability CONVERT=MP3 gives the ability to do 2. The client specifies a bitrate and length. (Or OGG, perhaps. MP3 is widely implemented, OGG is free of patents and there's good free code available.) 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 Jan 16 08:48:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8dO-0006zT-21; Wed, 16 Jan 2008 08:48:50 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JF8dN-0006zN-3S for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 08:48:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8dM-0006zF-PL for lemonade@ietf.org; Wed, 16 Jan 2008 08:48:48 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF8dM-0002RS-BC for lemonade@ietf.org; Wed, 16 Jan 2008 08:48:48 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 722C84AC73 for ; Wed, 16 Jan 2008 14:48:47 +0100 (CET) Message-Id: Date: Wed, 16 Jan 2008 14:48:47 +0100 From: Arnt Gulbrandsen To: Lemonade WG Subject: Re: [lemonade] strawman suggestion for convert References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Arnt Gulbrandsen writes: > I've seen basically three uses cases: (Actually I've seen more, but these are the ones I take seriously. I don't care about converting HTML to test, because IMHO effectively all handhelds can handle HTML. I don't care about converting character encodings, because clients already do that. Their web browsers do 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 Wed Jan 16 09:09:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8xW-0005Bs-PW; Wed, 16 Jan 2008 09:09:38 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JEsbO-0001Jx-6M for lemonade-confirm+ok@megatron.ietf.org; Tue, 15 Jan 2008 15:41:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JEsbN-0001Jo-Sz for lemonade@ietf.org; Tue, 15 Jan 2008 15:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEsZh-0000DW-QR for lemonade@ietf.org; Tue, 15 Jan 2008 15:39:57 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEsZe-0005Ix-OM for lemonade@ietf.org; Tue, 15 Jan 2008 15:39:57 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id m0FKdrWR028248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Jan 2008 12:39:53 -0800 X-Auth-Received: from D-128-208-197-177.dhcp4.washington.edu (D-128-208-197-177.dhcp4.washington.edu [128.208.197.177]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id m0FKdr9Q004894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jan 2008 12:39:53 -0800 Date: Tue, 15 Jan 2008 12:40:06 -0800 (PST) From: Mark Crispin To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: Last Call: draft-gulbrandsen-imap-enable (The IMAP ENABLE Extension) to Proposed Standard In-Reply-To: Message-ID: References: <478D0590.9070800@isode.com> User-Agent: Alpine 1.00 (LN8 908 2008-01-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.1.15.121603 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-TMDA-Confirmed: Tue, 15 Jan 2008 15:41:41 -0500 X-Mailman-Approved-At: Wed, 16 Jan 2008 09:09:37 -0500 Cc: lemonade@ietf.org, ietf-imapext@imc.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 On Tue, 15 Jan 2008, Arnt Gulbrandsen wrote: > Alexey Melnikov writes: >> One possible change to ENABLE was suggested by Cyrus on the mailing list >> when discussing CONVERT capability discovery, see >> >> >> A possible solution for this would be to change the ENABLE command to allow >> arbitrary parameters to capabilities enclosed in (), e.g. >> >> tag1 ENABLE CONVERT (("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED" >> "FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE" ("JPEG" >> "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320")) >> >> Servers would be required to ignore parameters for capabilities they don't >> understand. > > ENABLE so far has been about enabling server-side behaviour by explicit > command instead of as a side effect of another command. > > This change would add a general parameter facility for IMAP extensions. > Instead of just being on/off, IMAP extensions would now have complex > paramaters. > > I have two comments on that. > > 1. Most importantly, adding something that big one day before the end of IETF > LC is really bad. I might even raise an appeal to prevent that, to make sure > we get proper discussion and a new last call. It's unfair on reviewers to > more than double the complexity of an extension one day before the end of > IETF LC. > > 2. Less importantly, I'm not sure it's called for. We have only one use case, > and it's not even an awfully strong use case. (Should I make an alternative > suggestion for CONVERT? Not in this thread.) > > Arnt > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > Supplemental Web Site: > http://www.standardstrack.com/ietf/lemonade > -- 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 Jan 16 10:03:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9o0-0000G9-02; Wed, 16 Jan 2008 10:03:52 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JF9ny-0000G0-Cx for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF9ny-0000Fr-38 for lemonade@ietf.org; Wed, 16 Jan 2008 10:03:50 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF9nw-0008Vx-CN for lemonade@ietf.org; Wed, 16 Jan 2008 10:03:50 -0500 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, 16 Jan 2008 15:03:46 +0000 Message-ID: <478E1CAF.9050503@isode.com> Date: Wed, 16 Jan 2008 15:03:12 +0000 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: Arnt Gulbrandsen Subject: Re: [lemonade] strawman suggestion for convert 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: 538aad3a3c4f01d8b6a6477ca4248793 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 Arnt Gulbrandsen wrote: > All the suggestions I've seen center around providing enough > flexibility to cater to whatever is needed. How about having too > little flexibility instead? Solving the important 80%? > > I've seen basically three uses cases: > > 1. Convert a bodypart of some sort to a JPEG formatted for the > device's screen. (Sometimes this is a sequence of JPEGs, e.g. in the > case of a multipage PDF.) The bodypart may be an image, a PDF or even > an animation. Often it has MIME type application/octet-stream. > > 2. Convert a bodypart of some sort to to an MP3, chopping it off to > limited length. > > 3. Convert a video or audio bodypart to flash in a given resolution > and stream it. > > Accordingly my strawman has three parts: > > 3. Disregard case 3 for CONVERT. We don't do streaming inside IMAP. We > could "handle" it by mentioning that a streaming server can use > URLAUTH/URLFETCH to obtain the bodypart. Right. draft-ietf-lemonade-streaming-03.txt addresses this. > 1. Capability CONVERT=JPEG gives the ability to do 1. The client > specifies JPEG, x resolution, y resolution, whether to make the result > smaller or bigger if the aspect ratio is different, and a maximum > number of images. The server converts to JPEG if it can, resizes, > preserving aspect ratio, and sends the results. > > 2. Capability CONVERT=MP3 gives the ability to do 2. The client > specifies a bitrate and length. (Or OGG, perhaps. MP3 is widely > implemented, OGG is free of patents and there's good free code > available.) The problem I have with this proposal is that any given CONVERT= presupposes a list of conversion parameters a compliant server/client needs to understand. Which also means that every such extension needs to be a separate RFC (which would require an editor and some of them will have to be included into Lemonade Profile Bis). What would happen if the list of conversion parameters needs to be extended? And then I am also concerned that we will have an ever growing list of CONVERT-related capabilities in the CAPABILITY response. I would be glad to be proven wrong on this. Combining my comments together: I am a firm believer that we need a generic conversion parameter discovery mechanism. I don't really care if it is METADATA-based or not, even though I have my preferences. _______________________________________________ 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 Jan 16 10:21:48 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA5J-0001W1-Uu; Wed, 16 Jan 2008 10:21:45 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFA5J-0001Vu-3R for lemonade-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 10:21:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA5I-0001Vm-Q6 for lemonade@ietf.org; Wed, 16 Jan 2008 10:21:44 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFA5H-0000Ph-10 for lemonade@ietf.org; Wed, 16 Jan 2008 10:21:44 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id EAD5F4AC73 for ; Wed, 16 Jan 2008 16:21:41 +0100 (CET) Message-Id: Date: Wed, 16 Jan 2008 16:21:41 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] strawman suggestion for convert References: <478E1CAF.9050503@isode.com> In-Reply-To: <478E1CAF.9050503@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 writes: > The problem I have with this proposal is that any given CONVERT= > presupposes a list of conversion parameters a compliant server/client > needs to understand. Which also means that every such extension needs > to be a separate RFC (which would require an editor and some of them > will have to be included into Lemonade Profile Bis). What would > happen if the list of conversion parameters needs to be extended? Well, first of all, something will be replacing JPEG or MP3, and that's a rather bigger event than an RFC publication. > And then I am also concerned that we will have an ever growing list of > CONVERT-related capabilities in the CAPABILITY response. I would be > glad to be proven wrong on this. We'll have a new graphics target when a new format replaces JPEG as the widely-supported small format of choice, which I confidently predict will not happen in the next decade. Audio doesn't seem to change quite so slowly these days. But if we choose the right format, I'm pretty sure we can get at least five years before there's strong pressure for another format. And what else is there but audio and video? > Combining my comments together: I am a firm believer that we need a > generic conversion parameter discovery mechanism. I don't really care > if it is METADATA-based or not, even though I have my preferences. I don't see much enthusiasm for actually implementing the generic stuff. I don't mind metadata as an extension, but it's a lot of baggage if the goals are converting whathaveyou to JPEG or MP3. 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 Jan 17 02:45:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPRZ-0000Br-0j; Thu, 17 Jan 2008 02:45:45 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFPRW-0000Bh-QZ for lemonade-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 02:45:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFPRQ-000050-0V for lemonade@ietf.org; Thu, 17 Jan 2008 02:45:36 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFPRO-0003ab-Iy for lemonade@ietf.org; Thu, 17 Jan 2008 02:45:35 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0H7kLar001539 for ; Thu, 17 Jan 2008 01:46:28 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 09:44:45 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 09:44:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jan 2008 09:44:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Document repository not working? Thread-Index: AchY3Nbp0ZssqubQQrG1eUxH3yPwGg== From: To: X-OriginalArrivalTime: 17 Jan 2008 07:44:44.0968 (UTC) FILETIME=[D3CF3280:01C858DC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [lemonade] Document repository not working? 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: , Content-Type: multipart/mixed; boundary="===============0053565636==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============0053565636== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C858DC.D4096DE9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C858DC.D4096DE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I went to http://tools.ietf.org/wg/lemonade/ and it seems that there are = no documents are listed (none, 0). Perhaps I missed some announcement. Any clues? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 ------_=_NextPart_001_01C858DC.D4096DE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Document repository not working?

Hi all,
I went to http://tools.ietf.org/wg/lemonade/ and it seems that there are no = documents are listed (none, 0).
Perhaps I missed some = announcement.
Any clues?
Thank You.

Best regards: Zolt=E1n = =D6rd=F6gh
E-mail: zoltan = dot ordogh at nokia dot com
Phone: = +358 50 386 = 0566


------_=_NextPart_001_01C858DC.D4096DE9-- --===============0053565636== 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 --===============0053565636==-- From lemonade-bounces@ietf.org Thu Jan 17 12:45:16 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFYnd-0000aD-C1; Thu, 17 Jan 2008 12:45:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFYnc-0000a8-0J for lemonade-confirm+ok@megatron.ietf.org; Thu, 17 Jan 2008 12:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFYnb-0000a0-Mi for lemonade@ietf.org; Thu, 17 Jan 2008 12:45:07 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFYnb-00017e-7b for lemonade@ietf.org; Thu, 17 Jan 2008 12:45:07 -0500 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, 17 Jan 2008 17:45:04 +0000 Message-ID: <478F93FD.1040300@isode.com> Date: Thu, 17 Jan 2008 17:44:29 +0000 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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] Document repository not working? 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: 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 Zoltan.Ordogh@nokia.com wrote: > Hi all, > I went to _http://tools.ietf.org/wg/lemonade/_ and it seems that there > are no documents are listed (none, 0). > Perhaps I missed some announcement. > Any clues? > Thank You. > Hi Zoltan, I've forwarded your message to henrik@levkowetz.com, who maintain this page. _______________________________________________ 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 Jan 18 04:35:49 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFndY-0003OK-Io; Fri, 18 Jan 2008 04:35:44 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFndW-0003Nn-JE for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 04:35:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFndW-0003Nf-6Y for lemonade@ietf.org; Fri, 18 Jan 2008 04:35:42 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFndV-0005Yz-8G for lemonade@ietf.org; Fri, 18 Jan 2008 04:35:42 -0500 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, 18 Jan 2008 09:35:39 +0000 Message-ID: <478FD4CD.5060407@isode.com> Date: Thu, 17 Jan 2008 22:21:01 +0000 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: "Zoltan.Ordogh@nokia.com" Subject: Re: [lemonade] WGLC CONVERT References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 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 Zoltan.Ordogh@nokia.com wrote: >Hi all, >I have reviewed this draft several times earlier, so this time I have only a few, since most of my comments are editorial. > > Hi Zoltan, Thank you for the comments. >Great job Alexey, thank You! > > And Peter :-). >Comments: > >1. ToC: page numbers are missing (editorial). > > RFC-editor will add this during publication. >2. 4.2, par 5: typo in "MUST use the lowercases version" > Fixed. >3. 4.2, par 10(?): word change suggestion 'option'->'optional' in "supports the following types of option parameters" > Fixed. >4. 4.2, par 11: "As with conversion types, some "wildcarding" is permitted." 'some "wildcarding' sounds quite vague - can we specify 'some' exactly (to avoid misinterpretations)? > > I think the text is quite clear on this: As with conversion types, some "wildcarding" is permitted. Thus if the same parameters are allowed for all conversions to image/gif, then the server can store the one metadata value "/convert/@/@/image/gif/parameters". The first sentence points to wildcarding (use of "@") earlier in the same section. The second sentence gives an example. >5. 5., third last par.: typo in "The server ought to endeavour to preserver" > Fixed. >6. 5., third last par.: wording change suggestion. >Original: >"But in a case like this, where characters are split (legally!) between fragments of an encoded parameter what is the server to do? A safe answer is to consolidate parameters that are in pieces, convert them and emit them fragmenting them again if necessary to keep the line length less than 78." >Proposal: >"In case the characters are split (legally!) between fragments of an encoded parameter, the server MUST consolidate the parameter fragments, and convert, emit and re-fragment them as necessary in order to keep the line length less than 78." > Ok. >7. 5., third last par.: remove extra 'to' in "Comments embedded like this can be moved to after the parameter:" > Fixed. >8. 5. last sentence: wording change suggestion. >Original: >"It is important the encoded words be left as encoded words as to do otherwise may alter the semantics of structured headers." >Proposal: >"The encoded words MUST remain encoded, otherwise the semantics of structured headers might be inadvertently altered." > The original text is more like a SHOULD. Let me think if this text is Ok. >9. 6. par 1: typo in "minally" -> "minimally" > Changed. >10. 6. par 2: wording change suggestion. >Original: >"Note, a server implementation is not required to implement any conversion from the text MIME subtypes specified above, except for the mandatory to implement conversion described in section 6.1." >Proposal: >Original: >"Note, a server implementation is not required to support any conversion from the text MIME subtypes specified above, except for the mandatory transcoding parameters described in section 6.1." > Ok. >11. 6. par 3 and example under it. Should PIX-X, PIX-Y and IMAGE/JPG be lowercase? > Parameter names are case insensitive, so I've added the following sentence: Note, that according to [MEDIAFEAT-REG], transcoding parameter names are case-insensitive. MIME types are also case-insensitive. > (See case sensitivity in Section 5). > I am not sure which text in section 5 is relevant. Can you clarify? >12. 6.1 title: suggest change. >Original: >"Mandatory Transcoding support" >Proposal: >"Mandatory Transcoding parameters" > Changed. >13. 6.1 par 4: does this belong here? This section is about mandatory things, not SHOULDs. > > Formally you are correct, however I think this paragraph belongs to this section. The section can be renamed "Mandatory Transcoding parameters and other requirements", but this is a bit too obscure. >14. 6.2 title: suggest change. >Original: >"Additional features for mobile usage" >Proposal: >"Additional Transcoding parameters for mobile usage" > > This section doesn't talk about any transcoding parameters, so I think this change is wrong. >15. 7.3 par 2: wording change suggestion. >Original: > Clients MUST NOT remember sizes of converterted messages/ > body parts across multiple IMAP "sessions". (This requirement > allows an server implementation to upgrade its transcoding > component without breaking interoperability.) >Proposal: >"In order to guarantee safe upgrade of server transcoding components, clients MUST NOT assume that repeating a particular bodypart conversion yields the same result as a previous conversion of the very same bodypart - any characteristics of a bodypart might be different (format, size, etc)." > > The term "session" is defined in section 1.2 of RFC 3501 and has a special meaning (i.e. a sequence of command from mailbox opening and until its closure). Your text is less restrictive. My text is saying that a converted message/body part size can be cached for a duration of a session, but not beyond that. >16. 12.2 [MEMAIL] The draft has expired long ago - do we keep this? (referenced only once in Section 1.) > > Right. Unless there are objections, I will remove this informative reference. >17. General >In section one, we read this: "Conversion (adaptation, > transcoding) may be requested by the client and performed by the > server on a best effort basis or, when requested by the client, > decided by the server based on server's > knowledge of the client capabilities, user or administrator > preferences or server settings." >best effort -> clear >client capabilities -> not in the scope >administrator preferences -> not in the scope >server settings -> not in the scope > > While administrator preferences and server settings might not be in scope, I think they are an important implementation detail. So I think it is fine to reference them in an introductory section. >What about user preferences? I think that this is something that is in the scope since the user will store His/Her preferences on the server. Should this be described somehow? > > User preferences are specified using conversion parameters. I've added a sentence saying that. _______________________________________________ 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 Jan 18 05:39:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFocv-00089R-HV; Fri, 18 Jan 2008 05:39:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFocu-00089M-3N for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 05:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFoct-00087X-Nl for lemonade@ietf.org; Fri, 18 Jan 2008 05:39:07 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFocr-0004Qu-TH for lemonade@ietf.org; Fri, 18 Jan 2008 05:39:07 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0IAcjvU008572; Fri, 18 Jan 2008 12:39:00 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 12:38:54 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 12:38:54 +0200 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] WGLC CONVERT Date: Fri, 18 Jan 2008 12:38:59 +0200 Message-ID: In-Reply-To: <478FD4CD.5060407@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] WGLC CONVERT Thread-Index: AchZtYBNy3m+XOcKSOqRul0eeXDTLgABKNqw References: <478FD4CD.5060407@isode.com> From: To: X-OriginalArrivalTime: 18 Jan 2008 10:38:54.0745 (UTC) FILETIME=[52C66090:01C859BE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Alexey, thank you for the replies. I added a little here and there. 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: 18 January, 2008 00:21 >To: Ordogh Zoltan (Nokia-D-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] WGLC CONVERT > >>Great job Alexey, thank You! >> =20 >> >And Peter :-). Yes, of course. I am sorry about missing Peter. Peter, thank You. >>8. 5. last sentence: wording change suggestion. >>Original: >>"It is important the encoded words be left as encoded words=20 >as to do otherwise may alter the semantics of structured headers." >>Proposal: >>"The encoded words MUST remain encoded, otherwise the=20 >semantics of structured headers might be inadvertently altered." >> >The original text is more like a SHOULD. Let me think if this=20 >text is Ok. I did not mean changing the requirement here. If you feel that it is = necessary to allow exceptions, the SHOULD will be OK, too. >>11. 6. par 3 and example under it. Should PIX-X, PIX-Y and=20 >IMAGE/JPG be lowercase? >> >Parameter names are case insensitive, so I've added the=20 >following sentence: > Note, that according to [MEDIAFEAT-REG], transcoding parameter names > are case-insensitive. > >MIME types are also case-insensitive. > >> (See case sensitivity in Section 5). >> >I am not sure which text in section 5 is relevant. Can you clarify? Sorry, I messed up - this is in section 4.2: Note that names of server annotations are case-sensitive (see [METADATA]). In order to guaranty interoperability, clients and servers MUST use the lowercases version of and when constructing an annotation name described above. I just noticed a typo in the text above: garanty -> guarantee >>13. 6.1 par 4: does this belong here? This section is about=20 >mandatory things, not SHOULDs. >> =20 >> >Formally you are correct, however I think this paragraph=20 >belongs to this section. >The section can be renamed "Mandatory Transcoding parameters=20 >and other requirements", but this is a bit too obscure. I agree. I withdraw this comment. >>14. 6.2 title: suggest change. >>Original: >>"Additional features for mobile usage" >>Proposal: >>"Additional Transcoding parameters for mobile usage" >> =20 >> >This section doesn't talk about any transcoding parameters, so=20 >I think this change is wrong. I read this there: [quote] - Image conversions among the types image/gif, image/jpeg and image/png for at least the following parameters: o Size limit (i.e. reduce quality), o width, o height, o resize directive (crop, stretch, aspect ratio) The support for "depth" may also be of interest. [/quote] I thought that this section would be extended later with additional = parameters - if not, I agree that the current title is sufficient. >>15. 7.3 par 2: wording change suggestion. >>Original: >> Clients MUST NOT remember sizes of converterted messages/ >> body parts across multiple IMAP "sessions". (This requirement >> allows an server implementation to upgrade its transcoding >> component without breaking interoperability.) >>Proposal: >>"In order to guarantee safe upgrade of server transcoding=20 >components, clients MUST NOT assume that repeating a=20 >particular bodypart conversion yields the same result as a=20 >previous conversion of the very same bodypart - any=20 >characteristics of a bodypart might be different (format, size, etc)." >> =20 >> >The term "session" is defined in section 1.2 of RFC 3501 and=20 >has a special meaning (i.e. a sequence of command from mailbox=20 >opening and until its closure). >Your text is less restrictive. My text is saying that a=20 >converted message/body part size can be cached for a duration=20 >of a session, but not beyond that. Hmmm. I thought that my text was more restrictive for the clients = (performing the same conversion within the same session might not yield = the same result, neither). Why do we need to tie it to the session? That = would imply that the transcoding component cannot be updated when there = are open email sessions that have performaed transcoding earlier (e.g. = almost never). Also, the transcoding requests can be relayed to a = different server every time a request comes in, and one server might not = yield the same result as the other. Also, I think caching is not relevant here (if it is cached, it will = surely remain the same). _______________________________________________ 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 Jan 18 09:07:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrsd-0005IZ-OB; Fri, 18 Jan 2008 09:07:35 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFrsc-0005Gc-0x for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 09:07:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrsb-0005GK-Mv for lemonade@ietf.org; Fri, 18 Jan 2008 09:07:33 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFrsa-00005f-V1 for lemonade@ietf.org; Fri, 18 Jan 2008 09:07:33 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0IE7ETi014144; Fri, 18 Jan 2008 16:07:30 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:07:26 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 16:07:26 +0200 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] strawman suggestion for convert Date: Fri, 18 Jan 2008 16:07:31 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] strawman suggestion for convert Thread-Index: AchYRLTHLZqCNvW1QG6GfvJLSqMqZwBlMzSQ References: From: To: , X-OriginalArrivalTime: 18 Jan 2008 14:07:26.0624 (UTC) FILETIME=[746F9A00:01C859DB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Arnt, I think that what You are suggesting is very close to what we are doing. The format is the easiest thing to add: I do not think it matters = whether You write 'JPG', 'PNG' or 'MP3', 'OGG' after the 'CONVERT=3D'. I mean: when the protocol supports all the parameters for JPG and MP3, = the exact same parameters can be re-used in any picture and audio = format. (and adding support for video format will be just a combination = of the two) Streaming is different (however, I might want to transcode it [specify = the picture size/audio quality] before I start streaming) - but I = thought the idea was to get a link to the stream and transmit the stream = via a dedicated transport (e.g. not IMAP). 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 Arnt Gulbrandsen [mailto:arnt@oryx.com]=20 >Sent: 16 January, 2008 15:35 >To: Lemonade WG >Subject: [lemonade] strawman suggestion for convert > >All the suggestions I've seen center around providing enough=20 >flexibility to cater to whatever is needed. How about having=20 >too little flexibility instead? Solving the important 80%? > >I've seen basically three uses cases: > >1. Convert a bodypart of some sort to a JPEG formatted for the=20 >device's screen. (Sometimes this is a sequence of JPEGs, e.g.=20 >in the case of a multipage PDF.) The bodypart may be an image,=20 >a PDF or even an animation. Often it has MIME type=20 >application/octet-stream. > >2. Convert a bodypart of some sort to to an MP3, chopping it=20 >off to limited length. > >3. Convert a video or audio bodypart to flash in a given=20 >resolution and stream it. > >Accordingly my strawman has three parts: > >3. Disregard case 3 for CONVERT. We don't do streaming inside=20 >IMAP. We could "handle" it by mentioning that a streaming=20 >server can use URLAUTH/URLFETCH to obtain the bodypart. > >1. Capability CONVERT=3DJPEG gives the ability to do 1. The=20 >client specifies JPEG, x resolution, y resolution, whether to=20 >make the result smaller or bigger if the aspect ratio is=20 >different, and a maximum number of images. The server converts=20 >to JPEG if it can, resizes, preserving aspect ratio, and sends=20 >the results. > >2. Capability CONVERT=3DMP3 gives the ability to do 2. The=20 >client specifies a bitrate and length. (Or OGG, perhaps. MP3=20 >is widely implemented, OGG is free of patents and there's good=20 >free code >available.) > >Arnt > > >_______________________________________________ >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 Jan 18 10:48:26 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtSE-0006FZ-Ak; Fri, 18 Jan 2008 10:48:26 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFtSD-0006FT-Ex for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 10:48:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFtSD-0006FK-5L for lemonade@ietf.org; Fri, 18 Jan 2008 10:48:25 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFtSA-00021a-Mb for lemonade@ietf.org; Fri, 18 Jan 2008 10:48:25 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3EAB04AC7C; Fri, 18 Jan 2008 16:48:19 +0100 (CET) Message-Id: Date: Fri, 18 Jan 2008 16:48:19 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] strawman suggestion for convert References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Zoltan.Ordogh@nokia.com 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 Zoltan.Ordogh@nokia.com writes: > Hi Arnt, > I think that what You are suggesting is very close to what we are doing. Yes, very close, it's just that the last bit is the difficult one... > The format is the easiest thing to add: I do not think it matters > whether You write 'JPG', 'PNG' or 'MP3', 'OGG' after the 'CONVERT='. > I mean: when the protocol supports all the parameters for JPG and MP3, > the exact same parameters can be re-used in any picture and audio > format. (and adding support for video format will be just a > combination of the two) Several implementers have expressed great discomfort at the discovery mechanisms suggested. I wonder whether the best solution would be to say that autodiscovery is done using METADATA, that servers and clients may either do autodiscovery or implement and use only the MTI targets, and define a small, but useful set ot targets. JPEG and one audio format (OGG og MP3) IMO. If we do that, a server which only implements the MTI conversions doesn't need METADATA, and a client which only uses the MTI targets doesn't have to perform target disovery. 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 Jan 18 13:04:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFvZZ-0008Eg-7t; Fri, 18 Jan 2008 13:04:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JFvZY-0008EB-BT for lemonade-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 13:04:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFvZY-0008E3-1g for lemonade@ietf.org; Fri, 18 Jan 2008 13:04:08 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFvZW-0007xy-8R for lemonade@ietf.org; Fri, 18 Jan 2008 13:04:08 -0500 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, 18 Jan 2008 18:04:02 +0000 Message-ID: <4790E9F8.3000001@isode.com> Date: Fri, 18 Jan 2008 18:03:36 +0000 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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC CONVERT References: <478FD4CD.5060407@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: 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 Hi Zoltan, Zoltan.Ordogh@nokia.com wrote: >>>14. 6.2 title: suggest change. >>>Original: >>>"Additional features for mobile usage" >>>Proposal: >>>"Additional Transcoding parameters for mobile usage" >>> >>> >>This section doesn't talk about any transcoding parameters, so >>I think this change is wrong. >> >> >I read this there: >[quote] > - Image conversions among the types image/gif, > image/jpeg and image/png for at least the following parameters: > o Size limit (i.e. reduce quality), > o width, > o height, > o resize directive (crop, stretch, aspect ratio) > > The support for "depth" may also be of interest. >[/quote] >I thought that this section would be extended later with additional parameters - if not, I agree that the current title is sufficient. > > It is not going to be extended in this document. >>>15. 7.3 par 2: wording change suggestion. >>>Original: >>> Clients MUST NOT remember sizes of converterted messages/ >>> body parts across multiple IMAP "sessions". (This requirement >>> allows an server implementation to upgrade its transcoding >>> component without breaking interoperability.) >>>Proposal: >>>"In order to guarantee safe upgrade of server transcoding >>>components, clients MUST NOT assume that repeating a >>>particular bodypart conversion yields the same result as a >>>previous conversion of the very same bodypart - any >>>characteristics of a bodypart might be different (format, size, etc)." >>> >>> >>The term "session" is defined in section 1.2 of RFC 3501 and >>has a special meaning (i.e. a sequence of command from mailbox >>opening and until its closure). >>Your text is less restrictive. My text is saying that a >>converted message/body part size can be cached for a duration >>of a session, but not beyond that. >> >> >Hmmm. I thought that my text was more restrictive for the clients (performing the same conversion within the same session might not yield the same result, neither). Why do we need to tie it to the session? > As transcoding are expensive, I would like to allow servers to be able to cache results for the duration of a session. >That would imply that the transcoding component cannot be updated when there are open email sessions that have performaed transcoding earlier (e.g. almost never). > If the transcoding component needs to be upgraded, the server can force connection closure. I don't think such event would be frequent enough, so I don't see a reason for optimizing for it. >Also, the transcoding requests can be relayed to a different server every time a request comes in, and one server might not yield the same result as the other. > > True, but the server must be careful enough doing that, so that if a client asks for size or bodypartstructure of a convert body part first, then it would match the result returned to a subsequent request (in the same session) for the converted body part itself. >Also, I think caching is not relevant here (if it is cached, it will surely remain the same). > > My intent was to allow for caching. The requirement was formulated for clients, so maybe it would be better to reformulate it as a requirement on servers? _______________________________________________ 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 Jan 20 09:37:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGbIE-0000b5-GV; Sun, 20 Jan 2008 09:37:02 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGbID-0000ak-0q for lemonade-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 09:37:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGbIC-0000ab-Lk for lemonade@ietf.org; Sun, 20 Jan 2008 09:37:00 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGbIC-0000OO-0d for lemonade@ietf.org; Sun, 20 Jan 2008 09:37:00 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 20 Jan 2008 14:36:57 +0000 Message-ID: <47923410.7030804@isode.com> Date: Sat, 19 Jan 2008 17:32:00 +0000 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: Dan Karp Subject: Re: [lemonade] WGLC CONVERT References: <1099612670.16891198015680285.JavaMail.root@dogfood.zimbra.com> <476963B4.7000802@isode.com> In-Reply-To: <476963B4.7000802@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Alexey Melnikov wrote: > Dan Karp wrote: > >>> The work group last call for CONVERT ends 8 January 2008. Please have >>> at it. >> > Hi Dan, > Thank you for your comments. > >> The client can request header convertions using the BODY[...HEADER] >> CONVERT request, for example >> >> C: D001 FETCH 2 BODY[HEADER] >> S: * 2 FETCH (BODY[HEADER] {152} >> S: Date: Mon, 20 Apr 2007 20:05:43 +0200 >> S: From: peter >> S: To: Alexey >> S: Subject: =?USASCII*EN?Q?why encode this?= >> S: >> S: ) >> S: D001 OK >> >> C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER] >> S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {150} >> S: Date: Mon, 20 Apr 2007 20:05:43 +0200 >> S: From: peter >> S: To: Alexey >> S: Subject: =?UTF-8*EN?Q?why encode this?= >> S: >> S: ) >> S: D002 OK >> >> Was there a copy/paste error here? > > The example matches the current description, but ... >> From the explanatory text, I'd expect the second Subject header to >> read "why encode this" without the 2047 encoding. > > ... this is a valid point and I think the text should be adjusted > accordingly. I've added: Note that encoded-words might not be needed if the result can be represented entirely in US-ASCII. > The example can also be changed to convert from ISO-8859-1 to UTF-8. > >> The server ought to endeavour to preserver the headers during the >> conversion as much as possible. But in a case like this, where >> characters are split (legally!) between fragments of an encoded >> parameter what is the server to do? A safe answer is to >> consolidate parameters that are in pieces, convert them and >> emit them fragmenting them again if necessary to keep the line >> length less than 78. Comments embedded like this can be moved to >> after the parameter: >> >> C: D011 FETCH 3 BODY[1.MIME] >> S: * 3 FETCH (BODY[1.MIME] {118} >> S: Content-Type: text/plain; charset=utf-8; >> S: foo*0*=utf-8'fr'tr%c0; >> S: foo*1*(very)=%03s_m%c0; >> S: foo*2*=(nasty)%09chant >> S: >> S: D011 OK >> >> C: D012 CONVERT 3 (NIL) BODY[1.MIME] >> S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109} >> S: Content-Type: text/plain; charset=utf-8; >> S: foo*0*=utf-8'fr'tr%c0%03s_; >> S: foo*1*=%m%c0%09chant (very)(nasty) >> S: >> S: D012 OK >> >> Please leave it simple and explicitly allow servers to drop comments >> when transcoding headers. > > That is fine with me. Suggest text? I've changed one sentence to read: Comments embedded like this SHOULD be moved after the parameter, but MAY be removed entirely. Is this Ok with everybody? >> (Also, I'm not sure that RFC 2231 actually allows comments in either >> of those places...) We may also want to change the wording regarding >> 2231 encoding to flat-out state that > _______________________________________________ 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 Jan 20 09:37:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGbIP-0000qo-Lr; Sun, 20 Jan 2008 09:37:13 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGbIO-0000oF-Km for lemonade-confirm+ok@megatron.ietf.org; Sun, 20 Jan 2008 09:37:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGbIO-0000o7-Ag for lemonade@ietf.org; Sun, 20 Jan 2008 09:37:12 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGbIM-0005rW-Sf for lemonade@ietf.org; Sun, 20 Jan 2008 09:37:12 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 20 Jan 2008 14:37:04 +0000 Message-ID: <47923A12.1040400@isode.com> Date: Sat, 19 Jan 2008 17:57:38 +0000 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: Dan Karp Subject: Re: [lemonade] WGLC CONVERT References: <1099612670.16891198015680285.JavaMail.root@dogfood.zimbra.com> <476963B4.7000802@isode.com> <47923410.7030804@isode.com> In-Reply-To: <47923410.7030804@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) 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 Alexey Melnikov wrote: > I've changed one sentence to read: > > Comments embedded like this SHOULD be moved after the parameter, but > MAY be removed entirely. > > Is this Ok with everybody? I think the following is better: Comments embedded like this SHOULD be preserved during conversion, but MAY be removed entirely. If they are preserved, they MAY be moved after the parameter. _______________________________________________ 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 Jan 21 04:28:56 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGsxb-0006lN-Qn; Mon, 21 Jan 2008 04:28:55 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGsxa-0006lH-Ue for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 04:28:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGsxa-0006kW-HE for lemonade@ietf.org; Mon, 21 Jan 2008 04:28:54 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGsxZ-0007m7-OS for lemonade@ietf.org; Mon, 21 Jan 2008 04:28:54 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0L9Scij024370; Mon, 21 Jan 2008 11:28:48 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 11:28:37 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 11:28:37 +0200 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] strawman suggestion for convert Date: Mon, 21 Jan 2008 11:28:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] strawman suggestion for convert Thread-Index: AchZ6Y6Zxr1Q1kXuTiui5aKz3FACtACG9xZg References: From: To: , X-OriginalArrivalTime: 21 Jan 2008 09:28:37.0406 (UTC) FILETIME=[0048C3E0:01C85C10] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Arnt, >-----Original Message----- >From: ext Arnt Gulbrandsen [mailto:arnt@oryx.com]=20 >Sent: 18 January, 2008 17:48 >To: lemonade@ietf.org >Cc: Ordogh Zoltan (Nokia-D-MSW/Tampere) >Subject: Re: [lemonade] strawman suggestion for convert > >> The format is the easiest thing to add: I do not think it matters=20 >> whether You write 'JPG', 'PNG' or 'MP3', 'OGG' after the = 'CONVERT=3D'. >> I mean: when the protocol supports all the parameters for=20 >JPG and MP3,=20 >> the exact same parameters can be re-used in any picture and audio=20 >> format. (and adding support for video format will be just a=20 >> combination of the two) > >Several implementers have expressed great discomfort at the=20 >discovery mechanisms suggested. I understand that the problem is the discovery mechanism itself and not the parameters and formats (so, cutting back to JPG and MP3 only is not a good solution to the problem). I think everyone understands that METADATA will not work - it can only solve half of the problems (when clients understand what they are dealing with and they know what they want). (It is a different question that METADATA is not favoured). A client might have no clue what's inside the attachment (say, a PDF file (Dave's example)) - so it seems obvious that there has to be some sort of dynamic negotiation between the server and the client (to figure out exactly how things will be converted). But: do we want to tackle this problem? Isn't it easier to say "I want this attachment in a form that I understand" - and based on some info about the client (that has been disclosed previously), the server can try creating something that the client will surely understand. If there is no good match, or the server does not understand the content either, then the conversion simply fails. As for METADATA (in other words, the case when the client understand the attachment and knows what the target should be) - do we really need this? Isn't it easier to simply return the supported parameters whenever a request fails? (Note that OMA MEM will never allow a request to fail.) The current suggestions on the mailing list are: - Dave had a suggestion to tell the server what the client supports (MEDIACAPS), so the server can choose the "most acceptable" format from that list. - Dan had a suggestion to query the server about certain source/target types (CONVERSIONS). After all this, here is my strawman proposal: We have two cases (like Dave said): 1. Unpredictable (the client has no clue what it wants to convert and what will it receive). 2. Predictable conversions (the client knows what it wants to convert to what). To tackle case 1., we do what Dave suggested (the client declares its characteristics and codecs), and we allow "best match" conversion, when the server picks anything from what the client can display. To tackle case 2., we do nothing (just drop METADATA), we disclose the list of all parametersin some specification (or, just refer OMA STI parm list), and we allow the client to request any conversion (which is on the list). The requests will be: - successful (great!) - we get the content we wanted. - unsuccessful I: some parameters have been ignored (like colour depth), but the conversion has been done according to the requested format - we get the content we wanted, but not 100% accurately. - unsuccessful II: not supported format (or conversion), the server picks a new format according to the "best match" case - we do not get the content we wanted, but we get something that we surely can handle. - unsuccessful III: mismatch (attept to convert to something funny, like picture to audio), the same as "unsuccessful II". - unsuccessful IV: server does not understand the input, so it just sends the content without conversion - we do not get any conversion, we get the original. - fail I: bad request (syntax error or something) - client gets no content - fail II: bad input (cannot convert, the file format is broken) - client gets no content - fail III: contains virus (or, other screening issue) - client gets no content Finally, whenever the response code is "unsuccessful" or "fail", we can return the list of supported conversion formats/parms (whichever makes more sense in that context). What do all You think? _______________________________________________ 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 Jan 21 04:43:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGtC4-0005d6-PB; Mon, 21 Jan 2008 04:43:52 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGtC3-0005Xa-8p for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 04:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGtC2-0005XR-VH for lemonade@ietf.org; Mon, 21 Jan 2008 04:43:50 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGtC1-0008UY-5r for lemonade@ietf.org; Mon, 21 Jan 2008 04:43:50 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0L9hQSD012984; Mon, 21 Jan 2008 11:43:47 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 11:43:46 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 11:43:46 +0200 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] WGLC CONVERT Date: Mon, 21 Jan 2008 11:43:52 +0200 Message-ID: In-Reply-To: <4790E9F8.3000001@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] WGLC CONVERT Thread-Index: AchZ/IYWdJpcDZGvRG2SfITIP12DCACE+npQ References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@isode.com> From: To: X-OriginalArrivalTime: 21 Jan 2008 09:43:46.0187 (UTC) FILETIME=[1DF5BDB0:01C85C12] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Alexei, I added some comments below. 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: 18 January, 2008 20:04 >To: Ordogh Zoltan (Nokia-D-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] WGLC CONVERT > >Hi Zoltan, > >Zoltan.Ordogh@nokia.com wrote: > >>>>14. 6.2 title: suggest change. >>>>Original: >>>>"Additional features for mobile usage" >>>>Proposal: >>>>"Additional Transcoding parameters for mobile usage" >>>> =20 >>>> >>>This section doesn't talk about any transcoding parameters,=20 >so I think=20 >>>this change is wrong. >>> =20 >>> >>I read this there: >>[quote] >> - Image conversions among the types image/gif, >> image/jpeg and image/png for at least the following parameters: >> o Size limit (i.e. reduce quality), >> o width, >> o height, >> o resize directive (crop, stretch, aspect ratio) >> >> The support for "depth" may also be of interest. >>[/quote] >>I thought that this section would be extended later with=20 >additional parameters - if not, I agree that the current title=20 >is sufficient. >> =20 >> >It is not going to be extended in this document. Ok, then please consider this comment closed. >>>>15. 7.3 par 2: wording change suggestion. >>>>Original: >>>> Clients MUST NOT remember sizes of converterted messages/ >>>> body parts across multiple IMAP "sessions". (This=20 >requirement >>>> allows an server implementation to upgrade its transcoding >>>> component without breaking interoperability.) >>>>Proposal: >>>>"In order to guarantee safe upgrade of server transcoding=20 >components,=20 >>>>clients MUST NOT assume that repeating a particular bodypart=20 >>>>conversion yields the same result as a previous conversion of the=20 >>>>very same bodypart - any characteristics of a bodypart might be=20 >>>>different (format, size, etc)." >>>> =20 >>>> >>>The term "session" is defined in section 1.2 of RFC 3501 and has a=20 >>>special meaning (i.e. a sequence of command from mailbox opening and=20 >>>until its closure). >>>Your text is less restrictive. My text is saying that a converted=20 >>>message/body part size can be cached for a duration of a=20 >session, but=20 >>>not beyond that. >>> =20 >>> >>Hmmm. I thought that my text was more restrictive for the=20 >clients (performing the same conversion within the same=20 >session might not yield the same result, neither). Why do we=20 >need to tie it to the session? >> >As transcoding are expensive, I would like to allow servers to=20 >be able to cache results for the duration of a session. Servers? I thought that this word of warning was for the clients. >>That would imply that the transcoding component cannot be=20 >updated when there are open email sessions that have=20 >performaed transcoding earlier (e.g. almost never). >> >If the transcoding component needs to be upgraded, the server=20 >can force connection closure. I don't think such event would=20 >be frequent enough, so I don't see a reason for optimizing for it. True, makes sense and I accept this. Sessions are not cached ever, = right? (I try to recall quick reconnect here, if you remember.) >>Also, the transcoding requests can be relayed to a different=20 >server every time a request comes in, and one server might not=20 >yield the same result as the other. >> =20 >> >True, but the server must be careful enough doing that, so=20 >that if a client asks for size or bodypartstructure of a=20 >convert body part first, then it would match the result=20 >returned to a subsequent request (in the same session) for the=20 >converted body part itself. Well, you are the server implementors - if you are sure that everyone = will remember this without spelling this out explicitly in the = specification, I am ok with this explanation. >>Also, I think caching is not relevant here (if it is cached,=20 >it will surely remain the same). >> =20 >> >My intent was to allow for caching. >The requirement was formulated for clients, so maybe it would=20 >be better to reformulate it as a requirement on servers? Hehe, here we go - I was talking about the client perspective at all = times (since the text talks about clients). I guess we have an agreement = then, but from different points of view. I feel that the text for the = clients is valid and necessary, so could we change that and add a = similar text (yours + something from our comments above) for the = servers? Thank You. _______________________________________________ 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 Jan 21 06:09:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGuWc-00007s-Ti; Mon, 21 Jan 2008 06:09:10 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGuWb-00007T-KQ for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 06:09:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGuWb-00007K-Af for lemonade@ietf.org; Mon, 21 Jan 2008 06:09:09 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGuWa-0001nZ-QA for lemonade@ietf.org; Mon, 21 Jan 2008 06:09:09 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 21 Jan 2008 11:08:52 +0000 Subject: RE: [lemonade] strawman suggestion for convert References: In-Reply-To: MIME-Version: 1.0 Message-Id: <7814.1200913732.479605@peirce.dave.cridland.net> Date: Mon, 21 Jan 2008 11:08:52 +0000 From: Dave Cridland To: "Zoltan\.Ordogh\@nokia\.com" Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Mon Jan 21 09:28:43 2008, Zoltan.Ordogh@nokia.com wrote: > - fail III: contains virus (or, other screening issue) - client > gets no > content Well, there's no technical reason why a Windows virus can't be replaced with one suitable for Symbian, say. Also, should we be considering converting image spam to text for more convenient reading on mobile devices? 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 Mon Jan 21 06:54:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvE9-0003Ck-VY; Mon, 21 Jan 2008 06:54:09 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGvE9-0003CB-5A for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 06:54:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvE8-0003Bs-Qq for lemonade@ietf.org; Mon, 21 Jan 2008 06:54:08 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGvE8-0002l4-4T for lemonade@ietf.org; Mon, 21 Jan 2008 06:54:08 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0LBrx18018507; Mon, 21 Jan 2008 13:54:05 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 13:37:42 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 13:37:42 +0200 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] strawman suggestion for convert Date: Mon, 21 Jan 2008 13:37:49 +0200 Message-ID: In-Reply-To: <7814.1200913732.479605@peirce.dave.cridland.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] strawman suggestion for convert Thread-Index: AchcHg+FfWaQKpd/SpuQpSf8Lw3PmwAAbjiw References: <7814.1200913732.479605@peirce.dave.cridland.net> From: To: X-OriginalArrivalTime: 21 Jan 2008 11:37:42.0392 (UTC) FILETIME=[08A7D780:01C85C22] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Dave, >-----Original Message----- >From: ext Dave Cridland [mailto:dave@cridland.net]=20 >Sent: 21 January, 2008 13:09 >To: Ordogh Zoltan (Nokia-D-MSW/Tampere) >Cc: Enhancements to Internet email to support diverse service=20 >enivronments >Subject: RE: [lemonade] strawman suggestion for convert > >On Mon Jan 21 09:28:43 2008, Zoltan.Ordogh@nokia.com wrote: >> - fail III: contains virus (or, other screening issue) -=20 >client gets=20 >> no content > >Well, there's no technical reason why a Windows virus can't be=20 >replaced with one suitable for Symbian, say. Also, should we=20 >be considering converting image spam to text for more=20 >convenient reading on mobile devices? If the conversion fails, I guess the client should not get the mail = either, or, as an alternatives: - a) the whole mail could be replaced with a text telling the reason - = like "this mail contains harmful information for this client, therefore = it cannot be retireved. however, you may try another client" - b) replace the suspicious bodypart and add a text to the mail saying = that "a suspicious attachment has been replaced in this mail. if you = know what you are doing, you can get it from this URL:" But these are implementation issues. The majority of the spam should be filtered when they are deposited, and = the screening and virus scans should take place before deposit, too. But = of course people always find a way to slip things through the = safeguards. Today, all unfiltered spam is delivered to your mailbox - it = might be a waste of time to convert spam, but since it has passed the = filter, there is no way of telling that it is spam until the recipient = has decided that it is (something that you consider spam might not be a = spam for me), so the best thing we can do is to convert it and let the = user judge it for himseld (he will update his filters if he thinks that = it is spam). As for the type of the virus scans, I think that this is an = implementation issue and we should not mention anyhing specific (even = though we want to scan for all possible viruses, including Linux, Mac = and all other OSes as well). Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 > >Dave. >--=20 >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 Mon Jan 21 07:37:31 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvu7-0005wA-Fs; Mon, 21 Jan 2008 07:37:31 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGvu6-0005vz-EJ for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 07:37:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvu6-0005vr-4d for lemonade@ietf.org; Mon, 21 Jan 2008 07:37:30 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGvu4-0003iK-Im for lemonade@ietf.org; Mon, 21 Jan 2008 07:37:30 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0LCbJWH005401; Mon, 21 Jan 2008 14:37:26 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:37:25 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:37:26 +0200 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] METADATA use by Lemonade Profile Bis and suggestedsimplifications Date: Mon, 21 Jan 2008 14:37:32 +0200 Message-ID: In-Reply-To: <47691CC8.7020903@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] METADATA use by Lemonade Profile Bis and suggestedsimplifications Thread-Index: AchCQ0dzpa7WMkBAQcaat/vLMIFhbQZ4LJ+Q References: <47691CC8.7020903@isode.com> From: To: , X-OriginalArrivalTime: 21 Jan 2008 12:37:26.0077 (UTC) FILETIME=[60B2C6D0:01C85C2A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 all, please excuse my late reply on this thread - I was on vacation and I = have a long backlog to process. I have read all replies to this thread to date. First, I would like to respond to Alexey: You mention per-user and = per-mailbox METADATA. I am missing one thing from the list: per-client = METADATA. For that matter, I guess we still need to identify clients = somehow. Second, for the METADATA doubters: What is your actual concern? METADATA itself, or having one more IMAP = extension? If the concern is METADATA, please express all your concerns so that = they can be addressed in the draft. METADATA might not be right, but it = is in our power to make it right - or, if it's that bad, create = something else that does the job. If the concern is having yet another IMAP extension: IMAP was created to = be extensible - I do not see any restrictions in the IMAP = specifications. We can't dismiss new features because "there are so many = IMAP extensions already" - this is not a basis for argument. Also, I would like to point out that we do have requirements in OMA to = optimize network usage. In a mobile environment it is not very efficient = to open up (and keep open) a separate connection with every single IMAP = connection just to manage settings (and to notify/get the updates when = some other client or the administrator changes them). I do not think = that yet another extension is such a big deal when it is compared to = saving resources - if it is, we could make it part of Profile bis = specification instead, so that it is not necessary to have yet another = extension. Any thoughts? 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: 19 December, 2007 15:30 >To: Lemonade WG >Subject: [lemonade] METADATA use by Lemonade Profile Bis and=20 >suggestedsimplifications > >One of the goals of Lemonade Profile Bis is to try to satisfy=20 >majority of OMA MEM requirements. >Recently Zoltan and I (with some help with Dave Cridland) went=20 >through OMA MEM requirements trying to figure out how they can=20 >be mapped to Lemonade (and/or Sieve). My personal belief is=20 >that multiple requirements can be satisfied by IMAP METADATA=20 >extension (or ACAP, but I am not going to go into this=20 >discussion here). Here is an incomplete list of the=20 >corresponding OMA MEM requirements (some of them also need=20 >Sieve and Sieve Metadata extension): > >ADMIN-1: It MUST be possible to provision the mobile email=20 >client, based on any combination of who the user is and what=20 >the device is. >ADMIN-4: Authorized principals MUST be able to configure the=20 >settings of the user preferences/filters/configurable settings=20 >for a particular user >ADMIN-7: It MUST be possible for a user to view, edit and=20 >reset settings of a mobile email client >USAB-11: The mobile email enabler MUST support: > Different methods for notifying the client about new=20 >emails based on capabilities of the network > The ability for the user to select the transport method=20 >based on the capabilities of the client and network (e.g. SMS,=20 >Push, MMS etc) > The ability for the user to select if, when and how=20 >events are accessed by the client >USAB-16: Authorized principals MUST be able to select the ways=20 >that email events are sent to or accessed by the mobile email=20 >client and other email settings that may affect the server behaviour >USAB-28: The mobile email enabler SHOULD support=20 >activation/deactivation of auto-reply from the client.=20 >Automatically generated replies SHOULD avoid mail loops (RFC=20 >2821 and related RFCs) > > >After looking at this list Dave and I agreed that there=20 >doesn't seem to be any requirement to use per-mailbox=20 >metadata, per-user metadata seems to be sufficient. So I would=20 >like to propose that the METADATA extension is split into 2=20 >separate extensions: per-user METADATA and per-mailbox=20 >METADATA. I would also like to propose that only the former=20 >extension is included into Lemonade Profile Bis. > >Per-user metadata extensions is relatively easy to implement:=20 >it would only consist of GETMETADATA command (with mailbox=20 >parameter being ""), GETMETADATA response and SETMETADATA=20 >command, it doesn't depend on LIST-EXTENDED. Support for the=20 >COMPARATOR extension can be made optional. > >Opinions? > > > >_______________________________________________ >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 Jan 21 07:43:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvzl-0003gS-2A; Mon, 21 Jan 2008 07:43:21 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGvzj-0003gG-KW for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 07:43:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGvzj-0003g7-A7 for lemonade@ietf.org; Mon, 21 Jan 2008 07:43:19 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGvzi-0004qW-VZ for lemonade@ietf.org; Mon, 21 Jan 2008 07:43:19 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0LCiDXG019435; Mon, 21 Jan 2008 06:44:14 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:42:53 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:42:53 +0200 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] Profile-bis and IMAP-COMPRESS Date: Mon, 21 Jan 2008 14:42:59 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] Profile-bis and IMAP-COMPRESS Thread-Index: Acg/LN9yHkiQPKsgEdyt0AAWy4mm/wc/iZNQ References: From: To: , X-OriginalArrivalTime: 21 Jan 2008 12:42:53.0343 (UTC) FILETIME=[23C39AF0:01C85C2B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: alexey.melnikov@isode.com, stephane.maes@oracle.com 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, Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 >Three years from now, there is no reason to require a Lemonade=20 >server to support IMAP-COMPRESS. However, TLS needs to be=20 >there. Conversely, the >*market* will drive current implementations to do=20 >IMAP-COMPRESS today, but will also alleviate that pain over=20 >time. No reason to leave donkey tracks if we do not have to. Do You know something that we don't? _______________________________________________ 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 Jan 21 07:49:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGw5R-0008Bh-JI; Mon, 21 Jan 2008 07:49:13 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGw5Q-0008BR-4Y for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 07:49:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGw5P-0008BI-Pl for lemonade@ietf.org; Mon, 21 Jan 2008 07:49:11 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGw5P-00055M-6N for lemonade@ietf.org; Mon, 21 Jan 2008 07:49:11 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0LCmxP1017918; Mon, 21 Jan 2008 14:49:04 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:49:00 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 14:49:00 +0200 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] Profile-bis and IMAP Notifications Date: Mon, 21 Jan 2008 14:49:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] Profile-bis and IMAP Notifications Thread-Index: Acg/LVCyjxM19qsgEdyt0AAWy4mm/wc/fKaA References: From: To: , X-OriginalArrivalTime: 21 Jan 2008 12:49:00.0399 (UTC) FILETIME=[FE8BE7F0:01C85C2B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: alexey.melnikov@isode.com, stephane.maes@oracle.com 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, if I was not present in Vancouver, I would have said a clear yes. I am = not sure now, however because I think that in Vancouver I heard some = negative comments about NOTIFY in the room. I cannot recall who it was, what the comment was, all I have is a faint = memory (maybe it was Alexey pointing out that nobody implemented it = because people think that it is not necessary? - sorry if it is not the = case!). But I guess if there was a problem, people would start screaming, so I = say yes for now anyway... 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: 15 December, 2007 17:15 >To: lemonade@ietf.org >Cc: Alexey Melnikov; St=E9phane Maes >Subject: [lemonade] Profile-bis and IMAP Notifications > >WITH CHAIR HAT OFF, just a member of the work group... > >Right now we say Lemonade Message Stores MUST support IDLE and=20 >is silent on NOTIFY. > >I would offer Lemonade Message Stores MUST support NOTIFY and=20 >MAY support IDLE. > >Mandating support for IDLE means IDLE lives forever, even if=20 >no one uses it in the future. > >If there are other reasons for servers to support IDLE, like=20 >no extant client today supports NOTIFY, then market forces=20 >will ensure Lemonade Message Stores will support IDLE for the=20 >time being. > > >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 From lemonade-bounces@ietf.org Mon Jan 21 08:11:45 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwRF-0003fC-AZ; Mon, 21 Jan 2008 08:11:45 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGwRE-0003ZJ-IJ for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 08:11:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGwRE-0003Wn-4f for lemonade@ietf.org; Mon, 21 Jan 2008 08:11:44 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGwRC-0004oo-CI for lemonade@ietf.org; Mon, 21 Jan 2008 08:11:44 -0500 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, 21 Jan 2008 13:11:40 +0000 Message-ID: <479499E5.5080501@isode.com> Date: Mon, 21 Jan 2008 13:11:01 +0000 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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] strawman suggestion for convert 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: c0bedb65cce30976f0bf60a0a39edea4 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 Zoltan, Some comments (as an individual and not as an editor of CONVERT) on a part of your message: Zoltan.Ordogh@nokia.com wrote: >To tackle case 2., we do nothing (just drop METADATA), > I will send out a questionnaire on this shortly (later this week), so that we can hopefully get closure on this topic. However I have some comments on a part of your proposal: >we disclose the list of all parameters in some specification (or, just refer OMA STI parm >list) > There are 2 problems with this: 1). Extensibility problem: This implies that the list of supported parameters and that it can only be updated/changed by revising or extending the CONVERT document (or another companion document that will define them). I don't think this is convenient in long term. 2). IANA registry problem: We can't just reference the OMA STI list, as the CONVERT document is now using the IANA registry established by RFC 2506. We need to at least register OMA STI parameters in this registry. >, and we allow the client to request any conversion (which is on >the list). The requests will be: > - successful (great!) - we get the content we wanted. > - unsuccessful I: some parameters have been ignored > I would just note that the CONVERT requires that a parameter is always honored, unless the client explicitly allows to ignore it. We've talked about "you can ignore conversion parameters" parameter before, but this is still something that needs to be standardized (IMHO, in a document separate from IMAP CONVERT) and registered with IANA. >(like colour >depth), but the conversion has been done according to the requested >format - we get the content we wanted, but not 100% accurately. > - unsuccessful II: not supported format (or conversion), the server >picks a new format according to the "best match" case - we do not get >the content we wanted, but we get something that we surely can handle. > - unsuccessful III: mismatch (attept to convert to something funny, >like picture to audio), the same as "unsuccessful II". > - unsuccessful IV: server does not understand the input, so it just >sends the content without conversion - we do not get any conversion, we >get the original. > > Another note: the CONVERT extension as written would instead fail the conversion. > - fail I: bad request (syntax error or something) - client gets no >content > - fail II: bad input (cannot convert, the file format is broken) - >client gets no content > - fail III: contains virus (or, other screening issue) - client gets no >content >Finally, whenever the response code is "unsuccessful" or "fail", we can >return the list of supported conversion formats/parms (whichever makes >more sense in that context). > >What do all You think? > > I think your list of failure cases is useful, we just need to agree how they need to be handled. _______________________________________________ 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 Jan 21 08:25:22 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGweP-0001SI-S3; Mon, 21 Jan 2008 08:25:21 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGweO-0001Rq-JS for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 08:25:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGweO-0001Rh-9Z for lemonade@ietf.org; Mon, 21 Jan 2008 08:25:20 -0500 Received: from rnextsmtp.bea.com ([66.248.192.39] helo=repmmg02.bea.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGweM-0005Di-Dt for lemonade@ietf.org; Mon, 21 Jan 2008 08:25:20 -0500 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id m0LDPGjw025792; Mon, 21 Jan 2008 05:25:16 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id m0LDPCs9018297; Mon, 21 Jan 2008 05:25:15 -0800 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: quoted-printable Subject: Re: [lemonade] Profile-bis and IMAP Notifications Date: Mon, 21 Jan 2008 05:25:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Profile-bis and IMAP Notifications Thread-Index: Acg/LVCyjxM19qsgEdyt0AAWy4mm/wc/fKaAAAFylX4= From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: alexey.melnikov@isode.com, stephane.maes@oracle.com 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 My recollection is yours: the primary reason is everyone does IDLE in the s= erver today and no one does NOTIFY in the client. Since we expect lemonade = to be successful, we expect implementations of NOTIFY to happen. I also exp= ect that market forces will keep IDLE alive: if your customers have NOTIFY-= ignorant clients, you will supply them with an IDLE-capable server.=20 -- 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 Cc: alexey.melnikov@isode.com ; stephane.maes@or= acle.com Sent: Mon Jan 21 04:49:07 2008 Subject: RE: [lemonade] Profile-bis and IMAP Notifications Hi Eric, if I was not present in Vancouver, I would have said a clear yes. I am not = sure now, however because I think that in Vancouver I heard some negative c= omments about NOTIFY in the room. I cannot recall who it was, what the comment was, all I have is a faint mem= ory (maybe it was Alexey pointing out that nobody implemented it because pe= ople think that it is not necessary? - sorry if it is not the case!). But I guess if there was a problem, people would start screaming, so I say = yes for now anyway... Best regards: Zolt=C3=A1n =C3=96rd=C3=B6gh 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: 15 December, 2007 17:15 >To: lemonade@ietf.org >Cc: Alexey Melnikov; St=C3=A9phane Maes >Subject: [lemonade] Profile-bis and IMAP Notifications > >WITH CHAIR HAT OFF, just a member of the work group... > >Right now we say Lemonade Message Stores MUST support IDLE and=20 >is silent on NOTIFY. > >I would offer Lemonade Message Stores MUST support NOTIFY and=20 >MAY support IDLE. > >Mandating support for IDLE means IDLE lives forever, even if=20 >no one uses it in the future. > >If there are other reasons for servers to support IDLE, like=20 >no extant client today supports NOTIFY, then market forces=20 >will ensure Lemonade Message Stores will support IDLE for the=20 >time being. > > >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 > 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 Mon Jan 21 08:56:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGx8i-0007kO-AC; Mon, 21 Jan 2008 08:56:40 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JGx8g-0007kG-Lv for lemonade-confirm+ok@megatron.ietf.org; Mon, 21 Jan 2008 08:56:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGx8g-0007k6-C4 for lemonade@ietf.org; Mon, 21 Jan 2008 08:56:38 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGx8d-00064T-T9 for lemonade@ietf.org; Mon, 21 Jan 2008 08:56:38 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0LDu0Q8023297; Mon, 21 Jan 2008 15:56:33 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 15:55:44 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 15:55:44 +0200 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] strawman suggestion for convert Date: Mon, 21 Jan 2008 15:55:51 +0200 Message-ID: In-Reply-To: <479499E5.5080501@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] strawman suggestion for convert Thread-Index: AchcLzJZyOaioVr3RyKvQexbnLGwewAA+xVQ References: <479499E5.5080501@isode.com> From: To: X-OriginalArrivalTime: 21 Jan 2008 13:55:44.0800 (UTC) FILETIME=[515B0200:01C85C35] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Alexey, I added some comments below. 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: 21 January, 2008 15:11 >To: Ordogh Zoltan (Nokia-D-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] strawman suggestion for convert > >Hi Zoltan, >Some comments (as an individual and not as an editor of=20 >CONVERT) on a part of your message: > >Zoltan.Ordogh@nokia.com wrote: > >>To tackle case 2., we do nothing (just drop METADATA), >> >I will send out a questionnaire on this shortly (later this=20 >week), so that we can hopefully get closure on this topic. >However I have some comments on a part of your proposal: > >>we disclose the list of all parameters in some specification=20 >(or, just=20 >>refer OMA STI parm >>list) >> >There are 2 problems with this: >1). Extensibility problem: This implies that the list of=20 >supported parameters and that it can only be updated/changed=20 >by revising or extending the CONVERT document (or another=20 >companion document that will define them). I don't think this=20 >is convenient in long term. It is quite clear that we do not want to update the specification every = time someone proposes something new, or comes up with a new parameter. I had the understanding that syntax will be generic to support any = conversion parameters and Lemonade will specify only a limited set of = parameters that will be mandatory. It seems logical to leave the = non-mandatory parameters out completely, and leave a reference where = they can be found. The IANA registry is a good candidate. >2). IANA registry problem: We can't just reference the OMA STI=20 >list, as the CONVERT document is now using the IANA registry=20 >established by RFC 2506. We need to at least register OMA STI=20 >parameters in this registry. I do not disagree with this, but I recognize that there is work to be = done here. I have no idea what needs to be and how - but I offer my = assistance. >>, and we allow the client to request any conversion (which is on the=20 >>list). The requests will be: >> - successful (great!) - we get the content we wanted. >> - unsuccessful I: some parameters have been ignored >> >I would just note that the CONVERT requires that a parameter=20 >is always honored, unless the client explicitly allows to ignore it. >We've talked about "you can ignore conversion parameters"=20 >parameter before, but this is still something that needs to be=20 >standardized (IMHO, in a document separate from IMAP CONVERT)=20 >and registered with IANA. Indeed, this is a choice a client should be able to make. So, we can = split this into two, and say that it only occurs when excplicit = conversion was not requested, while the excplicit conversion will = obviously fail (and give a list of parameters/formats). > >>(like colour >>depth), but the conversion has been done according to the requested=20 >>format - we get the content we wanted, but not 100% accurately. >> - unsuccessful II: not supported format (or conversion), the server=20 >>picks a new format according to the "best match" case - we do not get=20 >>the content we wanted, but we get something that we surely can handle. >> - unsuccessful III: mismatch (attept to convert to something funny,=20 >>like picture to audio), the same as "unsuccessful II". >> - unsuccessful IV: server does not understand the input, so it just=20 >>sends the content without conversion - we do not get any=20 >conversion, we=20 >>get the original. >> =20 >> >Another note: the CONVERT extension as written would instead=20 >fail the conversion. Yes, I am aware of that - this is a proposal at this point. Might be = accepted, might change. If accepted, I guess we will have to update = CONVERT respectively. >> - fail I: bad request (syntax error or something) - client gets no=20 >>content >> - fail II: bad input (cannot convert, the file format is broken) -=20 >>client gets no content >> - fail III: contains virus (or, other screening issue) - client gets=20 >>no content Finally, whenever the response code is "unsuccessful" or=20 >>"fail", we can return the list of supported conversion formats/parms=20 >>(whichever makes more sense in that context). >> >>What do all You think? >> =20 >> >I think your list of failure cases is useful, we just need to=20 >agree how they need to be handled. Sounds good. I guess we should wait for feedback from the other = timezones as well. _______________________________________________ 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 Jan 23 06:04:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPO-0006ie-Fo; Wed, 23 Jan 2008 06:04:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JHdPN-0006iL-HQ for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPN-0006i3-6q for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHdPM-0003j6-QM for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 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, 23 Jan 2008 11:04:37 +0000 Message-ID: <47966588.7090505@isode.com> Date: Tue, 22 Jan 2008 21:52:08 +0000 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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC CONVERT References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@isode.com> <47965E6E.1000508@isode.com> In-Reply-To: <47965E6E.1000508@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Alexey Melnikov wrote: > Hi Zoltan, > >>>> Also, I think caching is not relevant here (if it is cached, it >>>> will surely remain the same). >>> >>> My intent was to allow for caching. >>> The requirement was formulated for clients, so maybe it would be >>> better to reformulate it as a requirement on servers? >> >> Hehe, here we go - I was talking about the client perspective at all >> times (since the text talks about clients). I guess we have an >> agreement then, but from different points of view. I feel that the >> text for the clients is valid and necessary, so could we change that >> and add a similar text (yours + something from our comments above) >> for the servers? > > Sounds good to me. After reviewing the document I think content caching is addressed in sufficient details at the end of section 7.3. I've extended the text I had, using some of the text you've suggested. Here is what I have now: In order to allow for upgrade of server transcoding components, clients MUST NOT assume that repeating a particular body part conversion in another IMAP "session" would yield the same result as a previous conversion of the very same bodypart - any characteristics of the converted body part might be different (format, size, etc). In particular clients MUST NOT cache sizes of converterted messages/body parts beyond duration of any IMAP "session", or use sizes obtained in one connection in another IMAP connection to the same server. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonaFrom lemonade-bounces@ietf.org Wed Jan 23 06:04:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPO-0006ie-Fo; Wed, 23 Jan 2008 06:04:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JHdPN-0006iL-HQ for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPN-0006i3-6q for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHdPM-0003j6-QM for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 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, 23 Jan 2008 11:04:37 +0000 Message-ID: <47966588.7090505@isode.com> Date: Tue, 22 Jan 2008 21:52:08 +0000 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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC CONVERT References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@isode.com> <47965E6E.1000508@isode.com> In-Reply-To: <47965E6E.1000508@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Alexey Melnikov wrote: > Hi Zoltan, > >>>> Also, I think caching is not relevant here (if it is cached, it >>>> will surely remain the same). >>> >>> My intent was to allow for caching. >>> The requirement was formulated for clients, so maybe it would be >>> better to reformulate it as a requirement on servers? >> >> Hehe, here we go - I was talking about the client perspective at all >> times (since the text talks about clients). I guess we have an >> agreement then, but from different points of view. I feel that the >> text for the clients is valid and necessary, so could we change that >> and add a similar text (yours + something from our comments above) >> for the servers? > > Sounds good to me. After reviewing the document I think content caching is addressed in sufficient details at the end of section 7.3. I've extended the text I had, using some of the text you've suggested. Here is what I have now: In order to allow for upgrade of server transcoding components, clients MUST NOT assume that repeating a particular body part conversion in another IMAP "session" would yield the same result as a previous conversion of the very same bodypart - any characteristics of the converted body part might be different (format, size, etc). In particular clients MUST NOT cache sizes of converterted messages/body parts beyond duration of any IMAP "session", or use sizes obtained in one connection in another IMAP connection to the same server. _______________________________________________ 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 Jan 23 06:04:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPO-0006iZ-Bg; Wed, 23 Jan 2008 06:04:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JHdPN-0006i2-7Z for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPM-0006ht-Oa for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:40 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHdPK-0003j6-Qr for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:40 -0500 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, 23 Jan 2008 11:04:35 +0000 Message-ID: <47965E6E.1000508@isode.com> Date: Tue, 22 Jan 2008 21:21:50 +0000 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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC CONVERT References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@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: 1.8 (+) 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 Hi Zoltan, Zoltan.Ordogh@nokia.com wrote: >>>>>15. 7.3 par 2: wording change suggestion. >>>>>Original: >>>>> Clients MUST NOT remember sizes of converterted messages/ >>>>> body parts across multiple IMAP "sessions". (This requirement >>>>> >>>>> allows an server implementation to upgrade its transcoding >>>>> component without breaking interoperability.) >>>>>Proposal: >>>>>"In order to guarantee safe upgrade of server transcoding components, >>>>> >>>>>clients MUST NOT assume that repeating a particular bodypart >>>>>conversion yields the same result as a previous conversion of the >>>>>very same bodypart - any characteristics of a bodypart might be >>>>>different (format, size, etc)." >>>>> >>>>> >>>>The term "session" is defined in section 1.2 of RFC 3501 and has a >>>>special meaning (i.e. a sequence of command from mailbox opening and >>>>until its closure). >>>>Your text is less restrictive. My text is saying that a converted >>>>message/body part size can be cached for a duration of a >>>>session, but not beyond that. >>>> >>>> >>>Hmmm. I thought that my text was more restrictive for the >>>clients (performing the same conversion within the same >>>session might not yield the same result, neither). Why do we >>>need to tie it to the session? >>> >>> >>As transcoding are expensive, I would like to allow servers to >>be able to cache results for the duration of a session. >> >Servers? I thought that this word of warning was for the clients. > The text is trying to cover both :-). >>>That would imply that the transcoding comde Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade From lemonade-bounces@ietf.org Wed Jan 23 06:04:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPO-0006iZ-Bg; Wed, 23 Jan 2008 06:04:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JHdPN-0006i2-7Z for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 06:04:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHdPM-0006ht-Oa for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:40 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHdPK-0003j6-Qr for lemonade@ietf.org; Wed, 23 Jan 2008 06:04:40 -0500 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, 23 Jan 2008 11:04:35 +0000 Message-ID: <47965E6E.1000508@isode.com> Date: Tue, 22 Jan 2008 21:21:50 +0000 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: Zoltan.Ordogh@nokia.com Subject: Re: [lemonade] WGLC CONVERT References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@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: 1.8 (+) 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 Hi Zoltan, Zoltan.Ordogh@nokia.com wrote: >>>>>15. 7.3 par 2: wording change suggestion. >>>>>Original: >>>>> Clients MUST NOT remember sizes of converterted messages/ >>>>> body parts across multiple IMAP "sessions". (This requirement >>>>> >>>>> allows an server implementation to upgrade its transcoding >>>>> component without breaking interoperability.) >>>>>Proposal: >>>>>"In order to guarantee safe upgrade of server transcoding components, >>>>> >>>>>clients MUST NOT assume that repeating a particular bodypart >>>>>conversion yields the same result as a previous conversion of the >>>>>very same bodypart - any characteristics of a bodypart might be >>>>>different (format, size, etc)." >>>>> >>>>> >>>>The term "session" is defined in section 1.2 of RFC 3501 and has a >>>>special meaning (i.e. a sequence of command from mailbox opening and >>>>until its closure). >>>>Your text is less restrictive. My text is saying that a converted >>>>message/body part size can be cached for a duration of a >>>>session, but not beyond that. >>>> >>>> >>>Hmmm. I thought that my text was more restrictive for the >>>clients (performing the same conversion within the same >>>session might not yield the same result, neither). Why do we >>>need to tie it to the session? >>> >>> >>As transcoding are expensive, I would like to allow servers to >>be able to cache results for the duration of a session. >> >Servers? I thought that this word of warning was for the clients. > The text is trying to cover both :-). >>>That would imply that the transcoding component cannot be >>>updated when there are open email sessions that have >>>performaed transcoding earlier (e.g. almost never). >>> >>If the transcoding component needs to be upgraded, the server >>can force connection closure. I don't think such event would >>be frequent enough, so I don't see a reason for optimizing for it. >> >> >True, makes sense and I accept this. Sessions are not cached ever, right? (I try to recall quick reconnect here, if you remember.) > We got rid of sessions in Quick Reconnect, so there is no issue here. >>>Also, the transcoding requests can be relayed to a different >>>server every time a request comes in, and one server might not >>>yield the same result as the other. >>> >>> >>True, but the server must be careful enough doing that, so >>that if a client asks for size or bodypartstructure of a >>convert body part first, then it would match the result >>returned to a subsequent request (in the same session) for the >>converted body part itself. >> >> >Well, you are the server implementors - if you are sure that everyone will remember this without spelling this out explicitly in the specification, I am ok with this explanation. > Ok, I will try to clarify this in the document. >>>Also, I think caching is not relevant here (if it is cached, >>>it will surely remain the same). >>> >>My intent was to allow for caching. >>The requirement was formulated for clients, so maybe it would >>be better to reformulate it as a requirement on servers? >> >> >Hehe, here we go - I was talking about the client perspective at all times (since the text talks about clients). I guess we have an agreement then, but from different points of view. I feel that the text for the clients is valid and necessary, so could we change that and add a similar text (yours + something from our comments above) for the servers? > Sounds good to me. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade Supplemental Web Site: http://www.standardstrack.com/ietf/lemonade ponent cannot be >>>updated when there are open email sessions that have >>>performaed transcoding earlier (e.g. almost never). >>> >>If the transcoding component needs to be upgraded, the server >>can force connection closure. I don't think such event would >>be frequent enough, so I don't see a reason for optimizing for it. >> >> >True, makes sense and I accept this. Sessions are not cached ever, right? (I try to recall quick reconnect here, if you remember.) > We got rid of sessions in Quick Reconnect, so there is no issue here. >>>Also, the transcoding requests can be relayed to a different >>>server every time a request comes in, and one server might not >>>yield the same result as the other. >>> >>> >>True, but the server must be careful enough doing that, so >>that if a client asks for size or bodypartstructure of a >>convert body part first, then it would match the result >>returned to a subsequent request (in the same session) for the >>converted body part itself. >> >> >Well, you are the server implementors - if you are sure that everyone will remember this without spelling this out explicitly in the specification, I am ok with this explanation. > Ok, I will try to clarify this in the document. >>>Also, I think caching is not relevant here (if it is cached, >>>it will surely remain the same). >>> >>My intent was to allow for caching. >>The requirement was formulated for clients, so maybe it would >>be better to reformulate it as a requirement on servers? >> >> >Hehe, here we go - I was talking about the client perspective at all times (since the text talks about clients). I guess we have an agreement then, but from different points of view. I feel that the text for the clients is valid and necessary, so could we change that and add a similar text (yours + something from our comments above) for the servers? > Sounds good to me. _______________________________________________ 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 Jan 23 07:30:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHek4-0000um-4h; Wed, 23 Jan 2008 07:30:08 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JHek2-0000uf-8S for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 07:30:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHek1-0000uW-Pf for lemonade@ietf.org; Wed, 23 Jan 2008 07:30:05 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHek1-0005JG-B6 for lemonade@ietf.org; Wed, 23 Jan 2008 07:30:05 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0NCUahG031721; Wed, 23 Jan 2008 06:31:05 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 14:29:52 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 14:29:52 +0200 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] WGLC CONVERT Date: Wed, 23 Jan 2008 14:30:00 +0200 Message-ID: In-Reply-To: <47966588.7090505@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] WGLC CONVERT Thread-Index: Achdr8DPVCm+F4JjT4yzo/WBcaPcdAAC8R8Q References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@isode.com> <47965E6E.1000508@isode.com> <47966588.7090505@isode.com> From: To: X-OriginalArrivalTime: 23 Jan 2008 12:29:52.0496 (UTC) FILETIME=[A72B4F00:01C85DBB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Alexey, this text is good, thank You. 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: 22 January, 2008 23:52 >To: Ordogh Zoltan (Nokia-D-MSW/Tampere) >Cc: lemonade@ietf.org >Subject: Re: [lemonade] WGLC CONVERT > >Alexey Melnikov wrote: > >> Hi Zoltan, >> >>>>> Also, I think caching is not relevant here (if it is cached, it=20 >>>>> will surely remain the same). >>>> >>>> My intent was to allow for caching. >>>> The requirement was formulated for clients, so maybe it would be=20 >>>> better to reformulate it as a requirement on servers? >>> >>> Hehe, here we go - I was talking about the client=20 >perspective at all=20 >>> times (since the text talks about clients). I guess we have an=20 >>> agreement then, but from different points of view. I feel that the=20 >>> text for the clients is valid and necessary, so could we=20 >change that=20 >>> and add a similar text (yours + something from our comments above)=20 >>> for the servers? >> >> Sounds good to me. > >After reviewing the document I think content caching is=20 >addressed in sufficient details at the end of section 7.3. >I've extended the text I had, using some of the text you've suggested.=20 >Here is what I have now: > > In order to allow for upgrade of server transcoding > components, clients MUST NOT assume that repeating a > particular body part conversion in another IMAP "session" > would yield the same result as a previous conversion of > the very same bodypart - any characteristics of the converted > body part might be different (format, size, etc). In > particular clients MUST NOT cache sizes of converterted > messages/body parts beyond duration of any IMAP "session", > or use sizes obtained in one connection in another IMAP > connection to the same server. _______________________________________________ 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 Jan 23 13:28:42 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHkL4-0001Zf-6L; Wed, 23 Jan 2008 13:28:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JHkL3-0001Za-5Y for lemonade-confirm+ok@megatron.ietf.org; Wed, 23 Jan 2008 13:28:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHkL2-0001ZR-RZ for lemonade@ietf.org; Wed, 23 Jan 2008 13:28:40 -0500 Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25] helo=sasl.smtp.pobox.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHkL1-0000eL-HB for lemonade@ietf.org; Wed, 23 Jan 2008 13:28:40 -0500 Received: from a-sasl-quonix (localhost [127.0.0.1]) by a-sasl-quonix.pobox.com (Postfix) with ESMTP id 75C5735F4; Wed, 23 Jan 2008 13:28:38 -0500 (EST) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by a-sasl-quonix.pobox.com (Postfix) with ESMTP id 17A3735F3; Wed, 23 Jan 2008 13:28:36 -0500 (EST) Date: Wed, 23 Jan 2008 10:28:32 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <102945261.20080123102832@pobox.com> To: Lemonade Subject: Re: [lemonade] WGLC CONVERT In-Reply-To: References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@isode.com> <47965E6E.1000508@isode.com> <47966588.7090505@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Noticed a typo (^^^ below). On Wed, 2008-01-23, Zoltan.Ordogh@nokia.com wrote: > Hi Alexey, > this text is good, thank You. >>Here is what I have now: >> >> In order to allow for upgrade of server transcoding >> components, clients MUST NOT assume that repeating a >> particular body part conversion in another IMAP "session" >> would yield the same result as a previous conversion of >> the very same bodypart - any characteristics of the converted >> body part might be different (format, size, etc). In >> particular clients MUST NOT cache sizes of converterted ^^^ >> messages/body parts beyond duration of any IMAP "session", >> or use sizes obtained in one connection in another IMAP >> connection to the same server. -- Bill McQuillan _______________________________________________ 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 Jan 24 06:36:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI0NJ-000589-29; Thu, 24 Jan 2008 06:36:05 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JI0NI-000584-59 for lemonade-confirm+ok@megatron.ietf.org; Thu, 24 Jan 2008 06:36:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI0NH-00057w-R9 for lemonade@ietf.org; Thu, 24 Jan 2008 06:36:03 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI0NH-0000aL-HR for lemonade@ietf.org; Thu, 24 Jan 2008 06:36:03 -0500 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, 24 Jan 2008 11:36:01 +0000 Message-ID: <4797B532.3010207@isode.com> Date: Wed, 23 Jan 2008 21:44:18 +0000 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: Bill McQuillan Subject: Re: [lemonade] WGLC CONVERT References: <478FD4CD.5060407@isode.com> <4790E9F8.3000001@isode.com> <47965E6E.1000508@isode.com> <47966588.7090505@isode.com> <102945261.20080123102832@pobox.com> In-Reply-To: <102945261.20080123102832@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Lemonade 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 Bill McQuillan wrote: >Noticed a typo (^^^ below). > > Fixed, thanks. _______________________________________________ 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 Jan 25 13:04:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISuF-0007N2-3o; Fri, 25 Jan 2008 13:03:59 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JISuE-0007Mw-5q for lemonade-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 13:03:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISuD-0007Mo-R7 for lemonade@ietf.org; Fri, 25 Jan 2008 13:03:57 -0500 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JISuD-0007aM-0r for lemonade@ietf.org; Fri, 25 Jan 2008 13:03:57 -0500 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, 25 Jan 2008 18:03:55 +0000 Message-ID: <479A2470.2050807@isode.com> Date: Fri, 25 Jan 2008 18:03:28 +0000 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 References: <39741682.27961198095404218.JavaMail.root@dogfood.zimbra.com> In-Reply-To: <39741682.27961198095404218.JavaMail.root@dogfood.zimbra.com> 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: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [lemonade] POLL: discovery of available conversions in CONVERT 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 everyone, After reviewing comments on CONVERT capability discovery received during and after WG LC it looks like there is no consensus (at least not yet) to use any particular mechanism. Please correct me if you think otherwise. So in order to figure out if the WG prefers any particular mechanism I suggest that people answer the following questionnaire. Some questions allow for multiple choices. Please list them in the order of your preferences. In order to correctly answer the questionnaire, one needs to: 1). have basic understand about CONVERT, ideally read draft-ietf-lemonade-convert-13.txt 2). review draft-daboo-imap-annotatemore-12.txt 3). review draft-melnikov-lemonade-convert-discovery-00.txt Please either send your replies to the Lemonade WG mailing list, or if you prefer - directly to me, CCing Peter Coates , Eric Burger , Glenn Parsons . Please send your response before February 8th. ========================================== Q1: Some questions regarding understanding of METADATA-SERVER (draft-daboo-imap-annotatemore-12.txt) extension (please answer to each question with Yes (true) or No (false)) A). METADATA-SERVER depends on LIST-EXTENDED extension (draft-ietf-imapext-list-extensions-18.txt). B). METADATA-SERVER depends on ENABLE extension (draft-gulbrandsen-imap-enable-05.txt). C). A server implementing METADATA-SERVER must implement multiple comparators. D). METADATA-SERVER requires implementation of both .priv and .shared Q2: Should CONVERT support the following conversion discovery mechanism: "Give me this body part in a format that I probably understand" (feel free to select multiple answers, unless you answer No or Undecided) Answers: 1). No 2). Yes, I am happy with Dave Cridland's proposal (see section 2.1 of draft-melnikov-lemonade-convert-discovery-00.txt or ) 3). Yes, but I would like to suggest another proposal 4). Undecided Q3: Should CONVERT support the following conversion discovery mechanism: "What can I turn this body part into?" (feel free to select multiple answers, unless you answer No or Undecided) Answers: 1). No 2). Yes, I prefer to use METADATA-SERVER extension (see section 2.2.1 of draft-melnikov-lemonade-convert-discovery-00.txt, also see draft-daboo-imap-annotatemore-12.txt for more information) 3). Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of draft-melnikov-lemonade-convert-discovery-00.txt or ) 4). Yes, I prefer Arnt's proposal for advertising target MIME types (or similar tokens) in the CAPABILITY response, e.g.: * CAPABILITY ... CONVERT=JPEG ... CONVERT=MP3 ... 5). Yes, but I would like to suggest another proposal 6). Undecided Q4: Should CONVERT support discovery of available conversion parameters for a particular conversion? (feel free to select multiple answers, unless you answer No or Undecided) Note that a separate question is asking if discovery should be optional or mandatory for servers to implement. Answers: 1). No, reporting that a particular conversion parameter is not supported (see CONVERT draft) is sufficient 2). Yes, I prefer to use METADATA-SERVER extension (see section 2.2.1 of draft-melnikov-lemonade-convert-discovery-00.txt, also see draft-daboo-imap-annotatemore-12.txt for more information) 3). Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of draft-melnikov-lemonade-convert-discovery-00.txt or ) 4). Yes, I would prefer to list available conversion parameters upon a CONVERT command failure caused by an unrecognized conversion parameter, for example: C: b002 CONVERT 2 ("text/plain" ("mumble" "hrrr")) (BINARY[3] BODYPARTSTRUCTURE[3]) S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] (ERROR "Parameter mumble is not supported for text/plain" BADPARAMETERS "text/html" "text/plain" ("mumble" "hrrr"))) S: * CONVERSIONS "text/html" "text/plain" "charset" "UNKNOWN-CHARACTER-REPLACEMENT" S: b002 OK Some conversions failed 5). Yes, but I would like to suggest another proposal 6). Undecided Q5: If you answered Yes to Q4: should the conversion parameter discovery be Mandatory or Optional for servers to support? _______________________________________________ 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 Jan 25 17:16:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIWqo-0002vp-Qf; Fri, 25 Jan 2008 17:16:42 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JIWqn-0002m3-DA for lemonade-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 17:16:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIWqn-0002hq-0g for lemonade@ietf.org; Fri, 25 Jan 2008 17:16:41 -0500 Received: from [2001:838:378:0:211:9ff:fe2c:e28e] (helo=turner.dave.cridland.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIWqm-0006aS-4A for lemonade@ietf.org; Fri, 25 Jan 2008 17:16:40 -0500 Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Fri, 25 Jan 2008 22:16:25 +0000 Subject: Re: [lemonade] POLL: discovery of available conversions in CONVERT References: <39741682.27961198095404218.JavaMail.root@dogfood.zimbra.com> <479A2470.2050807@isode.com> In-Reply-To: <479A2470.2050807@isode.com> MIME-Version: 1.0 Message-Id: <19909.1201299383.955052@peirce.dave.cridland.net> Date: Fri, 25 Jan 2008 22:16:23 +0000 From: Dave Cridland To: Enhancements to Internet email to support diverse service enivronments Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Spam-Score: -1.4 (-) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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've answered other bits of this to the relevant people privately. On Fri Jan 25 18:03:28 2008, Alexey Melnikov wrote: > 3). Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of > draft-melnikov-lemonade-convert-discovery-00.txt or > ) I basically like CONVERSIONS, but I wonder if it'd be possible to extend it so that you could either specify a source MIME type, or a source part. So you could say not only "What can you do with image/gif parts?" but also "What can you do with part 1.2.3 of UID 54?". As a suggested syntax: tag CONVERSIONS (UID 54 1.2.3) * > 4). Yes, I prefer Arnt's proposal for advertising target MIME types > (or similar tokens) in the CAPABILITY response, e.g.: > > * CAPABILITY ... CONVERT=JPEG ... CONVERT=MP3 ... > > I like the notion of this, but I wonder if it's ever going to go far enough. On the other hand, such a proposal does have the distinct benefit of being really simple for simple use-cases. So it's convenient to have a rubber stamp "I do these types of conversions", but that won't always be enough, and it also leaves open the rather tricky can of worms about which "standard conversion sets" we define and how. I also suspect that precisely what conversions are possible is likely to be a key differentiating factor between vendors, and that tying this down so that (honest) competition isn't possible would be a mistake that would cost the market as a whole. 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 Sun Jan 27 10:40:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ9cb-00012U-NP; Sun, 27 Jan 2008 10:40:37 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JJ9ca-00012C-15 for lemonade-confirm+ok@megatron.ietf.org; Sun, 27 Jan 2008 10:40:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJ9cZ-000122-Nf for lemonade@ietf.org; Sun, 27 Jan 2008 10:40:35 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJ9cY-0005WU-43 for lemonade@ietf.org; Sun, 27 Jan 2008 10:40:35 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 26 Jan 2008 16:36:36 +0000 Message-ID: <479B5F7E.4060202@isode.com> Date: Sat, 26 Jan 2008 16:27:42 +0000 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: Dave Cridland Subject: Re: [lemonade] POLL: discovery of available conversions in CONVERT References: <39741682.27961198095404218.JavaMail.root@dogfood.zimbra.com> <479A2470.2050807@isode.com> <19909.1201299383.955052@peirce.dave.cridland.net> In-Reply-To: <19909.1201299383.955052@peirce.dave.cridland.net> 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Dave Cridland wrote: > I've answered other bits of this to the relevant people privately. > > On Fri Jan 25 18:03:28 2008, Alexey Melnikov wrote: > >> 3). Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of >> draft-melnikov-lemonade-convert-discovery-00.txt or >> ) > > I basically like CONVERSIONS, but I wonder if it'd be possible to > extend it so that you could either specify a source MIME type, or a > source part. > > So you could say not only "What can you do with image/gif parts?" but > also "What can you do with part 1.2.3 of UID 54?". Do we really need this? > As a suggested syntax: > > tag CONVERSIONS (UID 54 1.2.3) * If we do need this, I suggest we extend the CONVERT command itself instead: just add a new data item requesting the list of all available conversions. _______________________________________________ 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 Jan 28 03:39:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPWV-00012F-MD; Mon, 28 Jan 2008 03:39:23 -0500 Received: from lemonade by megatron.ietf.org with local (Exim 4.43) id 1JJPWV-00012A-0N for lemonade-confirm+ok@megatron.ietf.org; Mon, 28 Jan 2008 03:39:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJPWU-000122-Iy for lemonade@ietf.org; Mon, 28 Jan 2008 03:39:22 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJPWT-0004iH-GC for lemonade@ietf.org; Mon, 28 Jan 2008 03:39:22 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m0S8cuIq013568; Mon, 28 Jan 2008 10:39:19 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:39:09 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 10:39:09 +0200 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] POLL: discovery of available conversions in CONVERT Date: Mon, 28 Jan 2008 10:39:18 +0200 Message-ID: In-Reply-To: <479A2470.2050807@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [lemonade] POLL: discovery of available conversions in CONVERT Thread-Index: AchffLWO571YrDgoS+KZYOMiU/QhGACB8F3w References: <39741682.27961198095404218.JavaMail.root@dogfood.zimbra.com> <479A2470.2050807@isode.com> From: To: , X-OriginalArrivalTime: 28 Jan 2008 08:39:09.0779 (UTC) FILETIME=[40551230:01C86189] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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 Alexey, please find my answers below. Q1: =3D=3D=3D A - yes (in case mailbox annotation is supported) B - yes (always) C - no (if there is none though, unicode-casemap is mandatory) D - yes (though not explicitly stated -> improve text?) Q2: =3D=3D=3D 2. Note: it looks good on paper, the question is how efficient and = useful this will be in practice (when will a client declare it, client = has to remember that it has declared it already, what happens if it was = not declared, etc). 3. While Dave's proposal is good, it might seem a logical choice to = store the client capabilites as METADATA (or, some other form) so that = it does not need to be disclosed during each session. This seems like a = good candidate for the client identification draft as well. Some vendors = expressed their concerns about the METADATA extension though - so it = might not be such a good idea in the end. Q3: =3D=3D=3D 1. If "I do not know what this thing can be turned into", it might be = more efficient to ask the server "just give me something I understand". 5. I suggested earlier to allow the client to request anything, and = return the possible conversions only when there was an error. Arnt's = proposal (advertise the list of MIME types) would imrove this: the MIME = type chosen by the client will be always correct and only the parameters = could be wrong. Q4: =3D=3D=3D 4. See improvement suggestion (using Arnt's proposal) above: Q3/5. Q5: =3D=3D=3D I think that answer Q4/4 implies that it would be mandatory. 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: 25 January, 2008 20:03 >To: Lemonade WG >Subject: [lemonade] POLL: discovery of available conversions in CONVERT > >Hi everyone, >After reviewing comments on CONVERT capability discovery=20 >received during and after WG LC it looks like there is no=20 >consensus (at least not yet) to use any particular mechanism.=20 >Please correct me if you think otherwise. > >So in order to figure out if the WG prefers any particular=20 >mechanism I suggest that people answer the following=20 >questionnaire. Some questions allow for multiple choices.=20 >Please list them in the order of your preferences. > >In order to correctly answer the questionnaire, one needs to: >1). have basic understand about CONVERT, ideally read=20 >draft-ietf-lemonade-convert-13.txt >2). review draft-daboo-imap-annotatemore-12.txt >3). review draft-melnikov-lemonade-convert-discovery-00.txt > >Please either send your replies to the Lemonade WG mailing=20 >list, or if you prefer - directly to me, CCing Peter Coates=20 >, Eric Burger , Glenn=20 >Parsons . > >Please send your response before February 8th. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Q1: Some questions regarding understanding of METADATA-SERVER >(draft-daboo-imap-annotatemore-12.txt) extension (please=20 >answer to each question with Yes (true) or No (false)) > >A). METADATA-SERVER depends on LIST-EXTENDED extension=20 >(draft-ietf-imapext-list-extensions-18.txt). >B). METADATA-SERVER depends on ENABLE extension=20 >(draft-gulbrandsen-imap-enable-05.txt). >C). A server implementing METADATA-SERVER must implement=20 >multiple comparators. >D). METADATA-SERVER requires implementation of both .priv and .shared > > >Q2: Should CONVERT support the following conversion discovery=20 >mechanism:=20 >"Give me this body part in a format that I probably understand" >(feel free to select multiple answers, unless you answer No or=20 >Undecided) > >Answers: >1). No >2). Yes, I am happy with Dave Cridland's proposal (see section=20 >2.1 of draft-melnikov-lemonade-convert-discovery-00.txt or >) >3). Yes, but I would like to suggest another proposal 4). Undecided > > >Q3: Should CONVERT support the following conversion discovery=20 >mechanism:=20 >"What can I turn this body part into?" >(feel free to select multiple answers, unless you answer No or=20 >Undecided) > >Answers: >1). No >2). Yes, I prefer to use METADATA-SERVER extension (see=20 >section 2.2.1 of=20 >draft-melnikov-lemonade-convert-discovery-00.txt, also see=20 >draft-daboo-imap-annotatemore-12.txt for more information) 3).=20 >Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of=20 >draft-melnikov-lemonade-convert-discovery-00.txt or >) >4). Yes, I prefer Arnt's proposal for advertising target MIME=20 >types (or similar tokens) in the CAPABILITY response, e.g.: > >* CAPABILITY ... CONVERT=3DJPEG ... CONVERT=3DMP3 ... > >5). Yes, but I would like to suggest another proposal 6). Undecided > > >Q4: Should CONVERT support discovery of available conversion=20 >parameters for a particular conversion? >(feel free to select multiple answers, unless you answer No or >Undecided) Note that a separate question is asking if=20 >discovery should be optional or mandatory for servers to implement. > >Answers: >1). No, reporting that a particular conversion parameter is=20 >not supported (see CONVERT draft) is sufficient 2). Yes, I=20 >prefer to use METADATA-SERVER extension (see section 2.2.1 of=20 >draft-melnikov-lemonade-convert-discovery-00.txt, also see=20 >draft-daboo-imap-annotatemore-12.txt for more information) 3).=20 >Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of=20 >draft-melnikov-lemonade-convert-discovery-00.txt or >) >4). Yes, I would prefer to list available conversion=20 >parameters upon a CONVERT command failure caused by an=20 >unrecognized conversion parameter, for example: > > C: b002 CONVERT 2 ("text/plain" ("mumble" "hrrr")) > (BINARY[3] BODYPARTSTRUCTURE[3]) > S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] > (ERROR "Parameter mumble is not supported for text/plain"=20 >BADPARAMETERS > "text/html" "text/plain" ("mumble" "hrrr"))) > S: * CONVERSIONS "text/html" "text/plain" "charset"=20 >"UNKNOWN-CHARACTER-REPLACEMENT" > S: b002 OK Some conversions failed =20 > >5). Yes, but I would like to suggest another proposal 6). Undecided > > >Q5: If you answered Yes to Q4: should the conversion parameter=20 >discovery be Mandatory or Optional for servers to support? > > > >_______________________________________________ >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 saspkzn@ansys.com Thu Jan 31 23:41:49 2008 Return-Path: X-Original-To: ietfarch-lemonade-archive@core3.amsl.com Delivered-To: ietfarch-lemonade-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61783A67E1 for ; Thu, 31 Jan 2008 23:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char FD hex): Received: ...m 4.62 (FreeBSD))\n\tid 1JL\375ZI-0001UJ-Ty; F[...] X-Spam-Flag: YES X-Spam-Score: 60.543 X-Spam-Level: ************************************************************ X-Spam-Status: Yes, score=60.543 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.1 HELO_EQ_DSL HELO_EQ_DSL * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 75.4.36.124] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 75.4.36.124] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 75.4.36.124] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [168.167.181.199 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ+rGgFPpZCc for ; Thu, 31 Jan 2008 23:41:49 -0800 (PST) Received: from 168-167-181-199.botsnetadsl.co.bw (unknown [168.167.181.199]) by core3.amsl.com (Postfix) with SMTP id 6500C3A6811 for ; Thu, 31 Jan 2008 23:41:45 -0800 (PST) Received: from [76.127.91.44] (helo=unc) by 168-167-181-199.botsnetadsl.co.bw with smtp (Exim 4.62 (FreeBSD)) id 1JLýZI-0001UJ-Ty; Fri, 1 Feb 2008 09:44:12 +0200 Message-ID: <002101c864a6$1b397c00$2c5b7f4c@unc> From: To: Subject: ***SPAM*** 60.543 (5) Happy I'll Be Your Bride Date: Fri, 1 Feb 2008 09:43:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 Surrounded by Love http://75.4.36.124/