From mailman-bounces@ietf.org Sat Jan 1 06:38:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12290 for ; Sat, 1 Jan 2005 06:38:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkhmE-0007jC-A5 for lemonade-web-archive@ietf.org; Sat, 01 Jan 2005 06:50:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgLZ-0003mJ-Sk for lemonade-web-archive@ietf.org; Sat, 01 Jan 2005 05:18:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: lemonade-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:06:01 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for lemonade-web-archive@ietf.org: List Password // URL ---- -------- lemonade@ietf.org ewunaw https://www1.ietf.org/mailman/options/lemonade/lemonade-web-archive%40ietf.org From lemonade-bounces@ietf.org Mon Jan 3 08:49:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28004 for ; Mon, 3 Jan 2005 08:49:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClSmL-0004PO-Q0 for lemonade-web-archive@ietf.org; Mon, 03 Jan 2005 09:01:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClSQx-0005iZ-Oj; Mon, 03 Jan 2005 08:39:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClSMK-0003b2-8F for lemonade@megatron.ietf.org; Mon, 03 Jan 2005 08:34:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26985 for ; Mon, 3 Jan 2005 08:34:54 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClSYU-00044w-Cs for lemonade@ietf.org; Mon, 03 Jan 2005 08:47:30 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j03DYpY00264; Mon, 3 Jan 2005 15:34:52 +0200 (EET) X-Scanned: Mon, 3 Jan 2005 15:34:35 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j03DYZXh009144; Mon, 3 Jan 2005 15:34:35 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00gRX7YH; Mon, 03 Jan 2005 15:34:33 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j03DYWx04470; Mon, 3 Jan 2005 15:34:32 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 Jan 2005 07:34:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Proposal for Content Adaptation Date: Mon, 3 Jan 2005 07:34:02 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3C4B@daebe005.americas.nokia.com> Thread-Topic: Proposal for Content Adaptation thread-index: AcTuZ8cFELmrYXELQjSoRsRV4w4foADKjF/Q To: , X-OriginalArrivalTime: 03 Jan 2005 13:34:03.0810 (UTC) FILETIME=[E423F020:01C4F198] X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On = Behalf Of ext Weingarten Jerry Sent: Thursday, December 30, 2004 7:05 AM ... > I would like to suggest a slight alternative to the CHANNEL=20 > suggestion=20 For clarity, would this be in lieu of the CHANNELCONVERSIONS=20 command suggested earlier on the list? Comments ... Sec 1.3 =20 "... it saves on queries from the Client to the Server as to=20 what transformations are possible." On the contrary this seems to increase the amount of traffic=20 between the client and the server. The mapping information for each body part is asked for each message. It is likely that if a server supports application/pdf -> text/plain for one message it will for all. So the client only needs to ask the general question not the same question for each message. Sec 1.5 This section is confusing. After issuing the CAFETCH we have the following statements. "Alternatively, the Client may choose to ignore the suggestions=20 provided by the Server in the response to the CAFETCH and use=20 the CHANNEL command to query the Server on what formats are=20 available to transcode the original media format to." Is this a second query? Of what form and why would a second=20 query be needed? "... the Client chooses to transcode a particular body part to=20 a media format not originally suggested by the server ..." Why would a client choose to do this? Sec 4 Why add the complication of parsing another BODYSTRUCTURE? A client will have already parsed a BODYSTRUCTURE from the=20 FETCH command. Why not just use a simply parsed list that uses the dotted naming convention for MIME parts. Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 4 06:06:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02089 for ; Tue, 4 Jan 2005 06:06:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clmiu-0002T6-TH for lemonade-web-archive@ietf.org; Tue, 04 Jan 2005 06:19:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClmTR-00034z-Bw; Tue, 04 Jan 2005 06:03:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClmS7-00025S-3i for lemonade@megatron.ietf.org; Tue, 04 Jan 2005 06:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01910 for ; Tue, 4 Jan 2005 06:02:12 -0500 (EST) Received: from smtp1.home.se ([213.214.194.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClmeQ-0002OS-L2 for lemonade@ietf.org; Tue, 04 Jan 2005 06:15:01 -0500 Received: from marek.pola@home.se [192.16.134.66] by home.se with NetMail ModWeb Module; Tue, 04 Jan 2005 11:56:15 +0100 From: "Marek Pola" To: lemonade@ietf.org Date: Tue, 04 Jan 2005 11:56:15 +0100 X-Mailer: NetMail ModWeb Module X-Sender: marek.pola@home.se MIME-Version: 1.0 Message-ID: <1104836175.3414a320marek.pola@home.se> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Push IMAP questions 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Hello all, I'm not sure this is the right place for my questions, in that case I apol= ogize, please advice me in that case where I can place them. I wish to start implementing the Push IMAP protocol that is currently in Dr= aft state. There are different communication protocols, https or tcp when accessing em= ails, and also for the outband notifications, there is a number of notifi= cation options to choose from. It doesn't say in the draft if any of thos= e options are mandatory? Obviously the servers will not support all optio= ns, but which ones must an implementation support? Also, is there a test server anywhere on which a implementation can be test= ed, or is this planned in the near future? Regards Marek Pola _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 4 08:18:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09728 for ; Tue, 4 Jan 2005 08:18:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clom6-0004zZ-UE for lemonade-web-archive@ietf.org; Tue, 04 Jan 2005 08:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CloUS-0004Qt-3N; Tue, 04 Jan 2005 08:12:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CloRo-0003MG-Ns for lemonade@megatron.ietf.org; Tue, 04 Jan 2005 08:10:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09182 for ; Tue, 4 Jan 2005 08:10:03 -0500 (EST) Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cloe6-0004pJ-Sh for lemonade@ietf.org; Tue, 04 Jan 2005 08:22:51 -0500 Received: from il-tlv-bridge01.comverse.com (il-tlv-bridge01.comverse.com [10.115.242.136]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id j04D9if17339; Tue, 4 Jan 2005 15:09:46 +0200 Received: from il-tlv-mail01.comverse.com ([10.115.242.87]) by il-tlv-bridge01.comverse.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 15:09:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 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] Proposal for Content Adaptation Date: Tue, 4 Jan 2005 15:09:03 +0200 Message-ID: <045FA14A4C4F904BA2D5BEDC37E16AF8F2C131@il-tlv-mail01.comverse.com> Thread-Topic: [lemonade] Proposal for Content Adaptation Thread-Index: AcTuZ8cFELmrYXELQjSoRsRV4w4foADKjF/QADFmtVA= From: "Weingarten Jerry" To: , X-OriginalArrivalTime: 04 Jan 2005 13:09:04.0561 (UTC) FILETIME=[90EE7210:01C4F25E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Hi, I obviously did not present my suggestion very clearly. I will try to restate it and thereby attempt to answer the questions and comments that Michael makes: 1. The idea presented was that the Client would issue a CAFETCH instead of a FETCH BODYSTRUCTURE command and receive in reply all information of the FETCH with the addition of extended information for each body part that indicates a list of media formats that the Server can make that body part available in. The Client can then issue a CHANNEL command to retrieve the parts in one of the suggested formats. This use would preclude the need for the CHANNELCONVERSIONS command usage. 2. There is a possibility that none of the suggested conversions are acceptable to the Client (who we are assuming is the final arbiter of what conversion to perform) and in such a case, the Client could still use the CHANNELCONVERSIONS command to interogate the Server for other possibilities of conversion and then, based on the responses received issue the appropriate CHANNEL command to perform the actual conversion. Now in reply to the comments and questions: >> For clarity, would this be in lieu of the CHANNELCONVERSIONS command suggested earlier on the list? Using scenario 1 above, yes it could save the use of this command. However, I do not advocate getting rid of the flexibility of having the command available for Clients that may opt, in special cases, to use scenario 2. >> It is likely that if a server supports application/pdf -> text/plain for one message it will for all. So the client only needs to ask the general question not the same question for each message. This comment makes a few assumptions that need to be clarified. For one, yes if the Server supports a certain conversion for one message it should support it for all messages but it may be possible that for different messages additional conversions may be suggested (e.g. if a Powerpoint file is only a single slide it may be appropriate to suggest an image conversion in addtion to a text conversion). Second issue is whether you are suggesting that the Client generate a database of the Server capabilities in order to save the queries? Third assumption id that the query is being made at the time of listing the contents of the mailbox and not at retrieval of the message, which needs clarification. >> This section is confusing. After issuing the CAFETCH we have the following statements... I hope my presentation (at the beginning of this message) clarified the confusion. >> Why add the complication of parsing another BODYSTRUCTURE? ... Again, I hope that the presentation at the beginning of the message clarified this. In addition, I am willing to have this just be defined as an extension of the FETCH command, however, my understanding was that the group (and imapext group) was not in favor of adding any new features to the FETCH command and therefore I presented it as a "new" command. Thanx for the comments, jerry _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 4 13:20:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04357 for ; Tue, 4 Jan 2005 13:20:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CltUO-0003Mi-1g for lemonade-web-archive@ietf.org; Tue, 04 Jan 2005 13:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CltGg-000415-Mj; Tue, 04 Jan 2005 13:18:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clt9B-0000Cp-7J for lemonade@megatron.ietf.org; Tue, 04 Jan 2005 13:11:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03557 for ; Tue, 4 Jan 2005 13:11:06 -0500 (EST) Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CltLZ-00035D-Nq for lemonade@ietf.org; Tue, 04 Jan 2005 13:23:59 -0500 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.191.11]) by agminet01.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j04IAMoG032303; Tue, 4 Jan 2005 10:10:24 -0800 Received: from rgmgw2.us.oracle.com (localhost [127.0.0.1]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j04IALwM024972; Tue, 4 Jan 2005 11:10:21 -0700 Received: from us.oracle.com (dhcp-4op5-4op6-west-144-25-174-17.us.oracle.com [144.25.174.17]) by rgmgw2.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j04IAJep024840; Tue, 4 Jan 2005 11:10:21 -0700 Message-Id: <200501041810.j04IAJep024840@rgmgw2.us.oracle.com> From: "Stephane H. Maes" To: Marek Pola , lemonade@ietf.org Subject: RE: [lemonade] Push IMAP questions Date: Tue, 4 Jan 2005 10:10:15 -0800 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2 60310 (11.0.6359) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Marek, Thanks for your interest. We will publish and implementation / interoperability guideline shortly tha= t goes beyond the protocol and address such issues. Today the protocol indeed lets you set / negotiate the transport but does n= ot specify which one should be supported at the minimum. For now we have taken the approach of always supporting the HTTP(s) and exp= erimenting with the others. TCP with TLS is also expected to be supported b= ut may fail to traverse firewalls. For that reason, I would suggest to firs= t target HTTP, even if less elegant... For notifications, I recommend to support SMS as at least wake-up of the cl= ient (on network where it makes sense), and in-band HTTP as well as UDP for= most of the notification on always-on networks (we will publish a UDP meth= od soon, may be in the upcoming next release of the draft). Feel free to contact me if you need any more details or help as you impleme= nt. Clearly feedback will be appreciated. = Also I could help you test interoperability against P-IMAP server and clien= ts. This requires setting up an account for you etc... Please contact me to= set that up when you are ready. Thanks Stephane _____ Stephane H. Maes, PhD, Director of Architecture - RTCC & Mobile, Oracle Corporation. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Marek Pola Sent: Tuesday, January 04, 2005 2:56 AM To: lemonade@ietf.org Subject: [lemonade] Push IMAP questions Hello all, I'm not sure this is the right place for my questions, in that case I apol= ogize, please advice me in that case where I can place them. I wish to start implementing the Push IMAP protocol that is currently in Dr= aft state. There are different communication protocols, https or tcp when accessing em= ails, and also for the outband notifications, there is a number of notifica= tion options to choose from. It doesn't say in the draft if any of those op= tions are mandatory? Obviously the servers will not support all options, bu= t which ones must an implementation support? Also, is there a test server anywhere on which a implementation can be test= ed, or is this planned in the near future? Regards Marek Pola _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 10 19:43:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18768 for ; Mon, 10 Jan 2005 19:43:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoALy-0007Jn-Cq for lemonade-web-archive@ietf.org; Mon, 10 Jan 2005 19:57:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoA6i-0002oS-Fu; Mon, 10 Jan 2005 19:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoA5Z-0002dh-TX for lemonade@megatron.ietf.org; Mon, 10 Jan 2005 19:40:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18596 for ; Mon, 10 Jan 2005 19:40:46 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoAJI-0007G7-03 for lemonade@ietf.org; Mon, 10 Jan 2005 19:55:00 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0B0eis22613; Tue, 11 Jan 2005 02:40:45 +0200 (EET) X-Scanned: Tue, 11 Jan 2005 02:48:51 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0B0mpli013385; Tue, 11 Jan 2005 02:48:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00kFIrjt; Tue, 11 Jan 2005 02:48:50 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0B0SBU07967; Tue, 11 Jan 2005 02:28:12 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jan 2005 18:24:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Proposal for Content Adaptation Date: Mon, 10 Jan 2005 18:24:08 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3C6F@daebe005.americas.nokia.com> Thread-Topic: [lemonade] Proposal for Content Adaptation thread-index: AcTuZ8cFELmrYXELQjSoRsRV4w4foADKjF/QADFmtVABRjGvEA== To: , X-OriginalArrivalTime: 11 Jan 2005 00:24:09.0360 (UTC) FILETIME=[DE26C900:01C4F773] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Weingarten Jerry [mailto:Jerry.Weingarten@comverse.com] > Sent: Tuesday, January 04, 2005 8:09 AM ... Thanks for the clarification. It helped. > 2. There is a possibility that none of the suggested conversions are > acceptable to the Client (who we are assuming is the final arbiter of > what conversion to perform) and in such a case, the Client could still > use the CHANNELCONVERSIONS command to interogate the Server for other > possibilities of conversion and then, based on the responses received > issue the appropriate CHANNEL command to perform the actual=20 > conversion. I still don't understand why the server would return different=20 conversion possibilities in each scenario. Why wouldn't the server=20 just tell the client all possible scenarios once? >=20 > >> It is likely that if a server supports application/pdf ->=20 > text/plain > for one message it will for all. So the client only needs to ask the > general question not the same question for each message. >=20 > This comment makes a few assumptions that need to be clarified. For > one, yes if the Server supports a certain conversion for one=20 > message it > should support it for all messages=20 Yes, we agree. So communicating this information per message is=20 redundant. > but it may be possible that for > different messages additional conversions may be suggested (e.g. if a > Powerpoint file is only a single slide it may be appropriate=20 > to suggest > an image conversion in addtion to a text conversion). =20 No assumption on my part here. I agree there may be several elements in the range of possible conversions. These multiple possibilities=20 should be communicated to the client all at once when asked. > Second issue is > whether you are suggesting that the Client generate a database of the > Server capabilities in order to save the queries?=20 No, I'm not suggesting this. I'm suggesting that the client ask per session not per message. This does not imply a database. > Third assumption id > that the query is being made at the time of listing the=20 > contents of the > mailbox and not at retrieval of the message, which needs=20 > clarification. I'm not sure what you mean "needs clarification". Yes, I'm suggesting that the client ask this at some time separate from the time the client asks for each message BODYSTRUCTURE. I=20 think this is reasonable. Clients do this type of thing all the=20 time. For example, when the mailbox is first selected a client may request all the body part MIME headers, then later request the actual body part. So I envision a scenario such as ... Select get supported conversions get message meta-data get message body parts as needed (possibly converted) Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 10 20:00:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19508 for ; Mon, 10 Jan 2005 20:00:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoAcU-0007bD-TW for lemonade-web-archive@ietf.org; Mon, 10 Jan 2005 20:14:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoAJF-0004gu-GM; Mon, 10 Jan 2005 19:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoAIC-0004DU-9m for lemonade@megatron.ietf.org; Mon, 10 Jan 2005 19:53:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19265 for ; Mon, 10 Jan 2005 19:53:49 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoAVt-0007Vr-Ga for lemonade@ietf.org; Mon, 10 Jan 2005 20:08:02 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0B0rms11653 for ; Tue, 11 Jan 2005 02:53:49 +0200 (EET) X-Scanned: Tue, 11 Jan 2005 03:01:32 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0B11WQa013088 for ; Tue, 11 Jan 2005 03:01:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00LVffGX; Tue, 11 Jan 2005 03:00:15 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0B0VaU11412 for ; Tue, 11 Jan 2005 02:31:36 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 Jan 2005 18:31:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2005 18:31:26 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3C70@daebe005.americas.nokia.com> Thread-Topic: Interim Mtg time thread-index: AcT3dOJ1PN7PLqFHTuOgpIQ+c53T4g== To: X-OriginalArrivalTime: 11 Jan 2005 00:31:27.0245 (UTC) FILETIME=[E326BBD0:01C4F774] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: quoted-printable Subject: [lemonade] Interim Mtg time 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable What was the start time on the 19th for this mtg? I seem to recall noon, = but I can not find the mail. Thanks, Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 11 17:13:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09754 for ; Tue, 11 Jan 2005 17:13:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUUh-0002gZ-HR for lemonade-web-archive@ietf.org; Tue, 11 Jan 2005 17:28:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUBZ-0008DI-9j; Tue, 11 Jan 2005 17:08:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTuN-0002PR-3M for lemonade@megatron.ietf.org; Tue, 11 Jan 2005 16:50:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07708 for ; Tue, 11 Jan 2005 16:50:32 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoU8F-00025L-KA for lemonade@ietf.org; Tue, 11 Jan 2005 17:04:56 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j0BLkpLt011142; Tue, 11 Jan 2005 16:46:51 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jan 2005 16:43:23 -0500 Message-ID: From: Eric Burger To: Michael.Wener@nokia.com Subject: RE: [lemonade] Interim Mtg time Date: Tue, 11 Jan 2005 16:43:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d It is noon. Information is at the Supplemental Web Page: http://flyingfox.snowshore.com/i-d/lemonade/ > -----Original Message----- > From: Michael.Wener@nokia.com [mailto:Michael.Wener@nokia.com] > Sent: Monday, January 10, 2005 7:31 PM > To: lemonade@ietf.org > Subject: [lemonade] Interim Mtg time > > > What was the start time on the 19th for this mtg? I seem to > recall noon, but I can not find the mail. > > Thanks, > Mike > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 17 11:00:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18132 for ; Mon, 17 Jan 2005 11:00:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZXX-0007xE-70 for lemonade-web-archive@ietf.org; Mon, 17 Jan 2005 11:15:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZB3-00080v-F8; Mon, 17 Jan 2005 10:52:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZ5q-0006fk-VS for lemonade@megatron.ietf.org; Mon, 17 Jan 2005 10:47:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16889 for ; Mon, 17 Jan 2005 10:47:00 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZKu-0007ed-Sm for lemonade@ietf.org; Mon, 17 Jan 2005 11:02:38 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HFkrl02096 for ; Mon, 17 Jan 2005 17:46:55 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 17:46:38 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0HFkckP031486 for ; Mon, 17 Jan 2005 17:46:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00vqrApe; Mon, 17 Jan 2005 17:46:36 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HFjZU03823 for ; Mon, 17 Jan 2005 17:45:35 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 09:41:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2005 09:41:47 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3C9A@daebe005.americas.nokia.com> Thread-Topic: RECONNECT 02 thread-index: AcT8qw4jg1XEQvKlTomIjozsUoWp2w== To: X-OriginalArrivalTime: 17 Jan 2005 15:41:49.0321 (UTC) FILETIME=[0EEC9790:01C4FCAB] X-Spam-Score: 0.9 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Subject: [lemonade] RECONNECT 02 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable The introduction has the statement "... a model can be=20 generated which will allow the user to reconnect to the=20 server in a fraction of the time required for a normal=20 connection" While this is not false it leaves the impression that this=20 "fraction" is large. Has it been quantified? Will the scheme as proposed really benefit the client to the extent implied=20 in the statement below, also in the introduction? "Usability of the IMAP email client can be improved by orders of magnitude if the IMAP client can connect/reconnect in a much shorter time and with fewer data transfers." I believe the answer to the later question is "no". Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 17 11:46:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22364 for ; Mon, 17 Jan 2005 11:46:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqaG3-0000fj-1j for lemonade-web-archive@ietf.org; Mon, 17 Jan 2005 12:01:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZtE-0002PO-0T; Mon, 17 Jan 2005 11:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZkg-0000JI-93 for lemonade@megatron.ietf.org; Mon, 17 Jan 2005 11:29:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20747 for ; Mon, 17 Jan 2005 11:29:11 -0500 (EST) From: Corby.Wilson@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZzk-0000Ej-2c for lemonade@ietf.org; Mon, 17 Jan 2005 11:44:49 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HGT8c27715 for ; Mon, 17 Jan 2005 18:29:09 +0200 (EET) X-Scanned: Mon, 17 Jan 2005 18:28:56 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j0HGSup2004734 for ; Mon, 17 Jan 2005 18:28:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00vNYudq; Mon, 17 Jan 2005 18:26:57 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0HGQux23719 for ; Mon, 17 Jan 2005 18:26:56 +0200 (EET) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 Jan 2005 10:21:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] RECONNECT 02 Date: Mon, 17 Jan 2005 10:21:36 -0600 Message-ID: <78E9902B779FD5428DB035B5F6A50EFB02BF480E@daebe004.americas.nokia.com> Thread-Topic: [lemonade] RECONNECT 02 thread-index: AcT8qw4jg1XEQvKlTomIjozsUoWp2wABXf3g To: , X-OriginalArrivalTime: 17 Jan 2005 16:21:37.0109 (UTC) FILETIME=[9E282050:01C4FCB0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Hi Mike, I will remove the ambiguous language from the draft. It has nothing to do with the technical details and has no supporting foundation. Corby Wilson =20 > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On > Behalf Of ext Michael.Wener@nokia.com > Sent: Monday, January 17, 2005 10:42 AM > To: lemonade@ietf.org > Subject: [lemonade] RECONNECT 02 >=20 > The introduction has the statement "... a model can be > generated which will allow the user to reconnect to the > server in a fraction of the time required for a normal > connection" >=20 > While this is not false it leaves the impression that this > "fraction" is large. Has it been quantified? Will the scheme > as proposed really benefit the client to the extent implied > in the statement below, also in the introduction? >=20 > "Usability of the IMAP email client can be improved by orders of > magnitude if the IMAP client can connect/reconnect in a much > shorter time and with fewer data transfers." >=20 > I believe the answer to the later question is "no". >=20 > Mike >=20 >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 17 14:13:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05002 for ; Mon, 17 Jan 2005 14:13:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqcZ9-0004NF-LY for lemonade-web-archive@ietf.org; Mon, 17 Jan 2005 14:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcBP-00022B-Ji; Mon, 17 Jan 2005 14:04:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqcAc-0001wu-I6 for lemonade@megatron.ietf.org; Mon, 17 Jan 2005 14:04:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04418 for ; Mon, 17 Jan 2005 14:04:08 -0500 (EST) Received: from mxout6.cac.washington.edu ([140.142.33.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqcPi-0004BT-5Z for lemonade@ietf.org; Mon, 17 Jan 2005 14:19:47 -0500 Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.2+UW05.01) with ESMTP id j0HJ47J7032541; Mon, 17 Jan 2005 11:04:07 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.13.3+UW05.01/8.13.2+UW05.01) with ESMTP id j0HJ47aZ010706; Mon, 17 Jan 2005 11:04:07 -0800 Date: Mon, 17 Jan 2005 11:04:07 -0800 (PST) From: Mark Crispin To: Corby.Wilson@nokia.com Subject: RE: [lemonade] RECONNECT 02 In-Reply-To: <78E9902B779FD5428DB035B5F6A50EFB02BF480E@daebe004.americas.nokia.com> Message-ID: References: <78E9902B779FD5428DB035B5F6A50EFB02BF480E@daebe004.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Mon, 17 Jan 2005 Corby.Wilson@nokia.com wrote: > I will remove the ambiguous language from the draft. It has nothing to > do with the technical details and has no supporting foundation. Thank you. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jan 19 13:15:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07691 for ; Wed, 19 Jan 2005 13:15:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKbe-0001Ki-Rx for lemonade-web-archive@ietf.org; Wed, 19 Jan 2005 13:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrKG9-0005aK-IU; Wed, 19 Jan 2005 13:08:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrK5t-0003g6-PR for lemonade@megatron.ietf.org; Wed, 19 Jan 2005 12:58:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06243 for ; Wed, 19 Jan 2005 12:58:11 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKLO-0000tp-Lx for lemonade@ietf.org; Wed, 19 Jan 2005 13:14:16 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0JHvcU14575 for ; Wed, 19 Jan 2005 12:57:38 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jan 2005 12:57:39 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D02D5CE90@zcarhxm0.corp.nortel.com> From: "Glenn Parsons" To: lemonade@ietf.org Date: Wed, 19 Jan 2005 12:57:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [lemonade] Interim agenda 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="===============0057210558==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0057210558== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FE50.56A8A3A5" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4FE50.56A8A3A5 Content-Type: text/plain; charset="iso-8859-1" Folks, Just a reminder that the interim will start at noon Pacific time today at 350 Oracle Pkwy in Redwood City. Stephane has indicated to us that lunch will be catered for us today and tomorrow. If you cannot make it, you can still join us in the jabber room: Room: lemonade Server: ietf.xmpp.org Logs: http://www.xmpp.org/ietf-logs/lemonade@ietf.xmpp.org/ Also, our current topic agenda is as follows: * Status review * Pull Trio * Quick Reconnect * Media Conversion * Channel * Profile (phase 1) * Goals (phase 2) Cheers, Glenn. ------_=_NextPart_001_01C4FE50.56A8A3A5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interim agenda

Folks,

Just a reminder that the interim will = start at noon Pacific time today at 350 Oracle Pkwy in Redwood = City.  Stephane has indicated to us that lunch will be catered for = us today and tomorrow.

If you cannot make it, you can still = join us in the jabber room:

Room:   = lemonade        =         Server: =         ietf.xmpp.org
Logs:   http://www.xmpp.org/ietf-logs/lemonade@ietf.xmpp.org/<= /A>

Also, our current topic agenda is as = follows:

    • Status review
  • Pull Trio
  • Quick Reconnect
  • Media Conversion
  • Channel
  • Profile (phase 1)
  • Goals (phase 2)


Cheers,
Glenn.

------_=_NextPart_001_01C4FE50.56A8A3A5-- --===============0057210558== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0057210558==-- From lemonade-bounces@ietf.org Wed Jan 19 13:15:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07769 for ; Wed, 19 Jan 2005 13:15:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKcP-0001M0-UQ for lemonade-web-archive@ietf.org; Wed, 19 Jan 2005 13:31:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrKG9-0005ae-Vn; Wed, 19 Jan 2005 13:08:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrK5t-0003g5-Dn for lemonade@megatron.ietf.org; Wed, 19 Jan 2005 12:58:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06240 for ; Wed, 19 Jan 2005 12:58:10 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKLO-0000tq-Rr for lemonade@ietf.org; Wed, 19 Jan 2005 13:14:15 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0JHvcU14579 for ; Wed, 19 Jan 2005 12:57:38 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jan 2005 12:57:39 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D02D5CE8F@zcarhxm0.corp.nortel.com> From: "Glenn Parsons" To: lemonade@ietf.org Date: Wed, 19 Jan 2005 12:57:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Subject: [lemonade] IESG Goals comments 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="===============0070658352==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0070658352== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FE50.560DAB4D" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4FE50.560DAB4D Content-Type: text/plain; charset="iso-8859-1" Folks, Here are some IESG comments on the Goals draft. We will be discussing this later today at the Lemonade interim. Cheers, Glenn. Date and Time: 2005-01-17, 18:56:01 Version: 05 Commented by: Hartman, Sam State before Comment: 0 State after Comment: 0 Comment: 1) This document proposes to make transcoding of media and other modification of messages significantly more common than is common today. No thought has been given to how this interacts with the deployability of S/MIME, PGP and other end-to-end mechanisms. For the most part the security community seems to have held its collective nose when examining smtp conneg, hoping that it won't get used much. I think that's the wrong approach to take with lemonade. I believe there's a central architectural issue that needs to be decided on a scope greater than one working group. How do we balance the needs of security against the needs of diverse messaging environments. I see three options. First, we can decide that it is critical that security be end-to-end and that systems like S/MIME are incompatible with lemonade. Second we can decide that we want to provide mechanisms so lemonade servers have access to the long-term keys needed to decrypt messages. A third option is to look at giving lemonade servers keys to individual messages as the MUA wants the messages manipulated. I don't think the lemonade group is the appropriate place to make this architectural decision, although I believe it has important input to give. Possible stakeholders include the IAB, IESG, security area and lemonade working group. I don't know how best to address this issue; I don't have enough experience on the IESG to know how we get all the right people together in a situation like this. 2) There is a presumption in the document and unfortunately the charter that smtp conneg is the right place to do content transformation for low-end devices. This seems to presume that a single message store will either be accessed by low-end or more normal devices. Perhaps for servers run by the phone providers that's true. However it seems like if you solve the content transformation issues at the IMAP layer rather than the SMTP layer, you can support dual use servers used both by low-end and less constrained clients. You only convert if the client cannot handle the current format of the message. If SMTP conneg is going to be the desired way of handling this, more explanation is needed. In addition, the document should either explain how dual-use servers will work or why they are not being handled. 3) The trust model is unclear. Sections 6.1.2.5, 6.2.2 both discuss trusted clients. For each operation involving trust, explain who the trusting party is, who the trusted party is and why it is reasonable to assume that there is a trust relationship between the parties. For the last part, it is probably sufficient to show that the parties will be run by the same administrative agent. 4) Section 6.1.2.4 seems at least partially inconsistent with IMAP4. In IMAP, flags are typically used to indicate that a message is scheduled for deletion. Why is it appropriate to change these semantics and require special mailbox support? 5) Section 7.2 assumes that it is an application layer issue to provide support for getting back to the right state in a session in case of network failure. First, IMAP is not the only application where this is an issue. SMTP will have the same problem sending large messages. Second, please explain why the application layer is the right place to solve this problem for this usage profile. Things that spring to my mind include a shim proxy that allows authentication and connection to an existing session. 6) Section 6.1.1.1 discusses a requirement for streaming. The charter says that this requirement will be addressed by using an external streaming protocol not by extending IMAP. No discussion of session security between the two protocols is made. From a security requirements standpoint I would expect that facilities to integrate external streaming protocol are sufficient such that if I have confidentiality for my IMAP session and desire confidentiality for my streaming session that these two sessions will be cryptographically bound together. I consider it an absolute requirement that any authentication sufficient to get you confidentiality for the IMAP session be sufficient to get you confidentiality for the streaming session. In the interests of showing that this requirement is possible to meet I present two approaches. One is to negotiate the confidentiality keys for the streaming session as part of IMAP. This seems similar to what happens with SIP. Another is to make sure the streaming protocol supports the same confidentiality technologies as IMAP (TLS and SASL) and to require that the same authenticated identities be used for both sessions. 7) The security considerations section is very weak. It should discuss the security implications of the architectural changes implied by this proposal. There are significant security implications of having the message store or MTA re-interpret messages. > Date and Time: 2005-01-06, 08:31:00 > Version: 05 > Commented by: Alvestrand, Harald > State before Comment: 0 > State after Comment: 0 > Comment: Reviewed by Mark Allman, Gen-ART > > His review: > > This one seems ready to go to me. Nicely written. We should do more of > these "why we are doing this" sort of documents. > > > ------_=_NextPart_001_01C4FE50.560DAB4D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IESG Goals comments

Folks,

Here are some IESG = comments on the Goals draft.

We will be = discussing this later today at the Lemonade interim.

Cheers,
Glenn.



Date and Time:  2005-01-17, = 18:56:01
Version:        = 05
Commented by:   Hartman, = Sam
State before Comment:   = 0
State after = Comment:    0
Comment:
        1) This document proposes to make transcoding of media = and other
=A0 modification of messages = significantly more common than is common
=A0 today.=A0 No thought has been = given to how this interacts with the
=A0 deployability of S/MIME, PGP and = other end-to-end mechanisms.=A0 For
=A0 the most part the security = community seems to have held its
=A0 collective nose when examining = smtp conneg, hoping that it won't
=A0 get used much.=A0 I think that's = the wrong approach to take with
=A0 lemonade.=A0 I believe there's a = central architectural issue that
=A0 needs to be decided on a scope = greater than one working group.=A0 How
=A0 do we balance the needs of = security against the needs of diverse
=A0 messaging environments.=A0 =
I see three options.=A0 First, we can = decide that it is critical that
security be end-to-end and that = systems like S/MIME are incompatible
with lemonade.=A0 Second we can = decide that we want to provide
mechanisms so lemonade servers have = access to the long-term keys
needed to decrypt messages.=A0 A = third option is to look at giving
lemonade servers keys to individual = messages as the MUA=A0 wants the
messages manipulated.=A0
I don't think the lemonade group is = the appropriate place to make this
architectural decision, although I = believe it has important input to
give.=A0 Possible stakeholders = include the IAB, IESG, security area and
lemonade working group.=A0 =A0 I = don't know how best to address this
issue; I don't have enough experience = on the IESG to know how we get
all the right people together in a = situation like this.
2) There is a presumption in the = document and unfortunately the
=A0 =A0 charter that smtp conneg is = the right place to do content
=A0 =A0 transformation for low-end = devices.=A0 This seems to presume that a
=A0 =A0 single message store will = either be accessed by low-end or more
=A0 =A0 normal devices.=A0 Perhaps = for servers run by the phone providers
=A0 =A0 that's true.=A0 However it = seems like if you solve the content
=A0 =A0 transformation issues at the = IMAP layer rather than the SMTP
=A0 =A0 layer, you can support dual = use servers used both by low-end and
=A0 =A0 less constrained clients.=A0 = You only convert if the client cannot
=A0 =A0 handle the current format of = the message.=A0 If SMTP conneg is going
=A0 =A0 to be the desired way of = handling this, more explanation is
=A0 =A0 needed.=A0 In addition, the = document should either explain how
=A0 =A0 dual-use servers will work or = why they are not being handled.
3) The trust model is unclear.=A0 = Sections 6.1.2.5, 6.2.2 both discuss
=A0 trusted clients.=A0 For each = operation involving trust, explain who
=A0 the trusting party is, who the = trusted party is and why it is
=A0 reasonable to assume that there = is a trust relationship between the
=A0 parties.=A0 For the last part, it = is probably sufficient to show that
=A0 the parties will be run by the = same administrative agent.
4) Section 6.1.2.4 seems at least = partially inconsistent with IMAP4.
=A0 =A0 In IMAP, flags are typically = used to indicate that a message is
=A0 =A0 scheduled for deletion.=A0 = Why is it appropriate to change these
=A0 =A0 semantics and require special = mailbox support?
5) Section 7.2 assumes that it is an = application layer issue to
=A0 provide support for getting back = to the right state in a session in
=A0 case of network failure.=A0 = First, IMAP is not the only application
=A0 where this is an issue.=A0 SMTP = will have the same problem sending
=A0 large messages.=A0 Second, please = explain why the application layer
=A0 is the right place to solve this = problem for this usage profile.
=A0 Things that spring to my mind = include a shim proxy that allows
=A0 authentication and connection to = an existing session.
6) Section 6.1.1.1 discusses a = requirement for streaming.=A0 The charter
=A0 says that this requirement will = be addressed by using an external
=A0 streaming protocol not by = extending IMAP.=A0 No discussion of session
=A0 security between the two = protocols is made.=A0 From a security
=A0 requirements standpoint I would = expect that facilities to integrate
=A0 external streaming protocol are = sufficient such that if I have
=A0 confidentiality for my IMAP = session=A0 and=A0 desire confidentiality
=A0 for my streaming session=A0 that = these two sessions will be
=A0 cryptographically bound = together.=A0 I consider it an absolute
=A0 requirement that=A0 any = authentication sufficient to get you
=A0 confidentiality for the IMAP = session be sufficient to get you
=A0 confidentiality for the streaming = session.=A0
In the interests of showing that this = requirement is possible to meet
I present two approaches.=A0 One is = to negotiate the confidentiality
keys for the streaming session as = part of IMAP.=A0 This seems similar to
what happens with SIP.=A0 Another is = to make sure the streaming protocol
supports the same confidentiality = technologies as IMAP (TLS and SASL)
and to require that the same = authenticated identities be used for both
sessions.
7) The security considerations = section is very weak.=A0 It should
=A0 =A0 discuss the security = implications of the architectural changes
=A0 =A0 implied by this proposal.=A0 = There are significant security
=A0 =A0 implications of having the = message store or MTA re-interpret
=A0 =A0 messages.





    Date and Time: 2005-01-06, 08:31:00 =
    Version: 05
    Commented by: Alvestrand, Harald =
    State before Comment: 0
    State after Comment: 0
    Comment: Reviewed by Mark Allman, = Gen-ART

    His review:

    This one seems ready to go to = me.  Nicely written.  We should do more of
    these "why we are doing = this" sort of documents.



------_=_NextPart_001_01C4FE50.560DAB4D-- --===============0070658352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0070658352==-- From lemonade-bounces@ietf.org Wed Jan 19 18:38:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09754 for ; Wed, 19 Jan 2005 18:38:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrPeP-0002pP-4l for lemonade-web-archive@ietf.org; Wed, 19 Jan 2005 18:54:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrPNh-0003V7-BZ; Wed, 19 Jan 2005 18:36:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrPH7-0002HY-JQ for lemonade@megatron.ietf.org; Wed, 19 Jan 2005 18:30:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09028 for ; Wed, 19 Jan 2005 18:30:06 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrPWe-0002ce-Fn for lemonade@ietf.org; Wed, 19 Jan 2005 18:46:14 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j0JNOGub010968 for ; Wed, 19 Jan 2005 18:24:16 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jan 2005 18:20:44 -0500 Message-ID: From: Eric Burger To: "IETF LEMONADE (E-mail)" Date: Wed, 19 Jan 2005 18:20:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [lemonade] WGLC BURL 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de This is an announcement of the Work Group Last Call for BURL: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-burl-00.txt Work Group Last Call will close 3 February 2005 at noon US Eastern Time. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jan 19 18:39:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09865 for ; Wed, 19 Jan 2005 18:39:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrPfm-0002qz-OS for lemonade-web-archive@ietf.org; Wed, 19 Jan 2005 18:55:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrPNh-0003VL-I8; Wed, 19 Jan 2005 18:36:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrPH8-0002Hc-QQ for lemonade@megatron.ietf.org; Wed, 19 Jan 2005 18:30:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09033 for ; Wed, 19 Jan 2005 18:30:08 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrPWg-0002ce-IN for lemonade@ietf.org; Wed, 19 Jan 2005 18:46:16 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j0JNOGub010969 for ; Wed, 19 Jan 2005 18:24:16 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jan 2005 18:20:43 -0500 Message-ID: From: Eric Burger To: "IETF LEMONADE (E-mail)" Date: Wed, 19 Jan 2005 18:20:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.6 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [lemonade] WGLC CATENATE 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c This is an announcement of the Work Group Last Call for CATENATE: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-03.txt This draft does not include one change that will be in -04 that will go for IETF Last Call, which is a typographical error found by Philip Guenther: http://www1.ietf.org/mail-archive/web/lemonade/current/msg01035.html Work Group Last Call will close 3 February 2005 at noon US Eastern Time. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 24 17:05:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07779 for ; Mon, 24 Jan 2005 17:05:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCbo-0001HL-9u for lemonade-web-archive@ietf.org; Mon, 24 Jan 2005 17:22:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCF2-0008Ds-Op; Mon, 24 Jan 2005 16:59:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtC8G-0003hD-BG for lemonade@megatron.ietf.org; Mon, 24 Jan 2005 16:52:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05208 for ; Mon, 24 Jan 2005 16:52:21 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCOp-0000PB-Tq for lemonade@ietf.org; Mon, 24 Jan 2005 17:09:32 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0OLqKn06234 for ; Mon, 24 Jan 2005 23:52:21 +0200 (EET) X-Scanned: Mon, 24 Jan 2005 23:52:02 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j0OLq2cd001153 for ; Mon, 24 Jan 2005 23:52:02 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 003xvXvq; Mon, 24 Jan 2005 23:51:59 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0OLbKx10115 for ; Mon, 24 Jan 2005 23:37:20 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 Jan 2005 15:36:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Jan 2005 15:36:47 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3CBB@daebe005.americas.nokia.com> Thread-Topic: LEMONADE WG Media Conversion Summary thread-index: AcUCXM4q1Vi8ErkJRauHUahe1EhsTQ== To: X-OriginalArrivalTime: 24 Jan 2005 21:36:48.0380 (UTC) FILETIME=[CF0B53C0:01C5025C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Subject: [lemonade] LEMONADE WG Media Conversion Summary 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable As per the chairs request below is my summary of the discussion=20 to date ... --------------------------- Abstract The problem of how to allow a client agent to gain access to media=20 conversion capability on an IMAP server has several potential=20 variations. This document outlines the issues as discussed within the LEMONADE working group. 1. Introduction and Overview In general, a client may be interested in receiving a MIME body part in streaming or non-streaming form. The case for retrieving a = converted MIME body part in streaming form will be described in the WG profile=20 document [PROFILE]. Therefore streaming mode will not be referred to = in the remainder of this document. This document deals strictly with the=20 case for non-streaming retrieval. The basic problem that needs to be solved is that the client must be=20 able to discover what it can convert, what it can convert it to and=20 while discovering this information it can not be flooded with large=20 amounts of superfluous information. Furthermore, once the client is informed of the server capabilities it must be able to effectively retrieve the body part in the converted=20 form. An effective way to describe the problem is as the server providing a conversion function with one set of content types (Domain) mapping to=09 another set of content types (Range). This mapping can potentially=20 be very verbose to communicate. This potential verbosity must be=20 mitigated. 2. Client Agent Capabilities A client is assumed to have sufficient intelligence to allow it to perform the following functions: 1) The ability to probe the IMAP server to discover what conversion capabilities the server has. 2) The ability to make an intelligent choice regarding the target=20 conversion. If the client software can not make a automatic = choice it is recognized the client can pass the decision on to the user, but this must be deferred to as a last option. 3) The ability to retrieve the converted body part to the client as=20 it would retrieve a non-converted body part. =20 Based on these premises the option to allow the server to=20 transparently perform conversions has been discarded within the=20 working group. Even if the conversion were based on a priori = knowledge, or out-of-band client capability discovery, the client must be=20 involved in making the choice to convert and retrieve the target body part. This avoids the server having to rewrite a message into a new=20 MIME structure. 3. IMAP Server Capabilities A server has the ability to change what it can convert at any time. The server may also have a potentially large set of conversion capabilities.=20 Given these two facts, a client must be able to both discover the servers capabilities dynamically, and limit the amount of server=20 capability communicated to the client to only that which the client is interested in at the moment. A server may still have a form of out-of-band client capability=20 discovery. This may be used to allow the server to discover additional client parametric capabilities. An example of this would be the server finding out parameters it may use to convert image formats. 4. Client Discovery It is important that an efficient protocol for communicating the = server capabilities be devised. The following options have been discussed in the WG: 1) CONNEG style (RFC2703). This was discounted as a possibility=20 because of it's complexity. This is a set intersection approach which is not needed because the client ultimately has a user it can ask to resolve an ambiguity of choice. 2) Client tells the server what Range it can accept. Server tells = the client the subset of these that it can convert to. This again is another version of the intersection approach. It does allow for=20 a reduction of information being sent to the client. The problem is that if done strictly it results in an ambiguous=20 situation for the client. The client never knows directly what=20 the mapping is. It does know what item in the Range it may = request , but it does not know what item in the Domain this is legal for. 3) Client uses a form of Capabilities discovery by just asking the=20 server what it supports for a particular item in the Domain of=20 content types. The server responds with the entire Range it=20 supports for that specific item. This approach has the advantage of being very dynamic, intuitive=20 and direct. The disadvantage is that the client may receive Range = items which it does not care about. 4) Server explicitly declares it's conversion capability in a=20 CAPABILITY response. This has two serious drawbacks: one, it=20 may make for a very cumbersome CAPABILITies string, and two, the client gets information it may not be interested in. 5. Client Retrieval Once the client has decided that it wants to convert a specific MIME=20 body part, and it has discovered that the server supports the desired conversion, it must retrieve the converted bytes. These bytes should be retrievable much the same way a FETCH allows=20 the retrieval of an un-converted body part. Some form of partial=20 retrieval should be allowed as well. The partial retrieval is useful in the same scenarios it would be useful during a normal FETCH. Conversion occurs on the IMAP server as the client requests it. 6. Bandwidth Optimization It has been observed that a form of bandwidth optimization may be achievable by using the same mechanism used in conversion to=20 retrieve MIME body parts in a compressed form. An optimal approach would be to allow the following functionality: =20 1) The client may request a conversion retrieval in a compressed format. 2) The server would support NULL conversions for all MIME types in the Domain. The client would then be able to retrieve an=20 unconverted MIME body part in compressed form by requesting a NULL conversion. 7. Normative References [PROFILE] Maes, S. H., A. Melnikov,"Lemonade Profile",=20 draft-ietf-lemonade-profile-XX , 2005. 8. Author Michael J. Wener Nokia, Inc. Phone: (906) 202-0538 EMail: Michael.Wener@Nokia.com _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 24 17:54:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12270 for ; Mon, 24 Jan 2005 17:54:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDMl-0003Ox-8C for lemonade-web-archive@ietf.org; Mon, 24 Jan 2005 18:11:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCwr-0002aE-0Q; Mon, 24 Jan 2005 17:44:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCw6-0002Eb-AO for lemonade@megatron.ietf.org; Mon, 24 Jan 2005 17:43:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11178 for ; Mon, 24 Jan 2005 17:43:51 -0500 (EST) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDCg-0002uR-OV for lemonade@ietf.org; Mon, 24 Jan 2005 18:01:03 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0OMhpgX001496; Mon, 24 Jan 2005 14:43:52 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0OMhpZY010525 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 Jan 2005 14:43:51 -0800 Date: Mon, 24 Jan 2005 14:43:53 -0800 (Pacific Standard Time) From: Mark Crispin To: Michael.Wener@nokia.com Subject: Re: [lemonade] LEMONADE WG Media Conversion Summary In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3CBB@daebe005.americas.nokia.com> Message-ID: References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3CBB@daebe005.americas.nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 I would like to ask for a minor clarification, and offer a strawman. Is it anticipated that media conversion would be a facility of specialized IMAP servers? Or, alternatively, is this expected to become a more or less "mandatory to implement extension" in general purpose servers? I am asking because server-based media conversion may be a severe burden to a general purpose server (as well as having potential security implications), and any mandate to that effect is potentially harmful. I'm not necessarily opposed, but am sounding a note of caution. On the other hand, an extension that is focused on specialized servers, using a capability-driven mechanism, seems to be a very obvious means of addressing the issue and would have my enthusiastic support. The assumption here is that this is a performance optimization, and not a requirement for clients to work at all. I persist in my belief that all clients should work with a base-level server without requiring any extension. The capability mechanism need not be cumbersome; there could be a general capability for media conversions, and then an additional negotiation for the supported conversion mechanism(s). Although this likely adds an RTT, that may be less costly in the overall scheme of things. As a strawman, suppose the server offers MEDIACONVERSIONS as an extension. There could then be a command to query as to the available conversions; or, alternatively, there could be a means by which the client offers a list of its desired set of media conversions and the server then reports the intersection between these and what the server supports. A shortcut that avoids the extra RTT is a form of FETCH that lists the client-acceptable media conversions, and the server can then choose one and perform it in the response. One of these client-specified conversions is "no conversion", which would tell the server to send the data back unconverted rather than barf. How such a command is engineered would largely depend upon client needs. In spite of my note of caution above, I think that this is potentially a very exciting and useful path for IMAP to take. It is one that was anticipated in IMAP from the onset. So, please treat my caution as a "do it right" rather than a "don't do it." :-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 24 19:23:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22893 for ; Mon, 24 Jan 2005 19:23:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtElB-0007VZ-SU for lemonade-web-archive@ietf.org; Mon, 24 Jan 2005 19:40:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtEBS-0001su-E4; Mon, 24 Jan 2005 19:03:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtE7A-0000Pb-C6 for lemonade@megatron.ietf.org; Mon, 24 Jan 2005 18:59:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20012 for ; Mon, 24 Jan 2005 18:59:20 -0500 (EST) From: Michael.Wener@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtENk-0006Ir-Ip for lemonade@ietf.org; Mon, 24 Jan 2005 19:16:34 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0ONx7l25328; Tue, 25 Jan 2005 01:59:15 +0200 (EET) X-Scanned: Tue, 25 Jan 2005 02:07:59 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j0P07x10020674; Tue, 25 Jan 2005 02:07:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 006opkEH; Tue, 25 Jan 2005 02:07:57 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0ONvWU13242; Tue, 25 Jan 2005 01:57:32 +0200 (EET) Received: from daebe005.NOE.Nokia.com ([10.241.35.105]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 Jan 2005 17:51:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] LEMONADE WG Media Conversion Summary Date: Mon, 24 Jan 2005 17:51:15 -0600 Message-ID: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3CBC@daebe005.americas.nokia.com> Thread-Topic: [lemonade] LEMONADE WG Media Conversion Summary thread-index: AcUCZlYbJAGFEMFkS+qYQBGJwzw6AAACDusw To: X-OriginalArrivalTime: 24 Jan 2005 23:51:16.0400 (UTC) FILETIME=[97F57B00:01C5026F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: mrc@ndcms.cac.washington.edu > [mailto:mrc@ndcms.cac.washington.edu]On Behalf Of ext Mark Crispin > Sent: Monday, January 24, 2005 5:44 PM ... > Is it anticipated that media conversion would be a facility=20 > of specialized=20 > IMAP servers? =20 This is how I see it. >=20 > I am asking because server-based media conversion may be a=20 > severe burden=20 I agree. > The capability mechanism need not be cumbersome; there could=20 > be a general=20 > capability for media conversions, and then an additional=20 > negotiation for=20 > the supported conversion mechanism(s). Although this likely=20 > adds an RTT,=20 > that may be less costly in the overall scheme of things. Any additional RTT could be lessened by allowing the client to=20 gain this information at times of it's choosing, and making it apply generally, i.e. to any specific body part as long as that body part was of the correct content type. You can see a related discussion based on Lyndon's proposal at ... http://www1.ietf.org/mail-archive/web/lemonade/current/msg00993.html Mike _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 25 00:15:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12135 for ; Tue, 25 Jan 2005 00:15:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtJJU-0000HY-U8 for lemonade-web-archive@ietf.org; Tue, 25 Jan 2005 00:32:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtJ22-0004WM-Q3; Tue, 25 Jan 2005 00:14:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtIzn-0002vC-SU for lemonade@megatron.ietf.org; Tue, 25 Jan 2005 00:12:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12022 for ; Tue, 25 Jan 2005 00:12:04 -0500 (EST) From: Corby.Wilson@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtJGR-0000BM-HF for lemonade@ietf.org; Tue, 25 Jan 2005 00:29:20 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0P5Bol25024; Tue, 25 Jan 2005 07:11:59 +0200 (EET) X-Scanned: Tue, 25 Jan 2005 07:11:28 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0P5BSVm006796; Tue, 25 Jan 2005 07:11:28 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 003pl1Hq; Tue, 25 Jan 2005 07:11:26 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0P5BQx17453; Tue, 25 Jan 2005 07:11:26 +0200 (EET) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 Jan 2005 23:11:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] LEMONADE WG Media Conversion Summary Date: Mon, 24 Jan 2005 23:11:24 -0600 Message-ID: <78E9902B779FD5428DB035B5F6A50EFB02CBA50A@daebe004.americas.nokia.com> Thread-Topic: [lemonade] LEMONADE WG Media Conversion Summary thread-index: AcUCZ9n9ZUWA3Y0nQieMxdNZ23hcjwAM6r4g To: , X-OriginalArrivalTime: 25 Jan 2005 05:11:25.0470 (UTC) FILETIME=[5174F3E0:01C5029C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Excellent comments. Content transformation is VERY expensinve (especially immages). An IMAP server which does onboard content transformation will have many problems with connection timeouts as people try to transform data. The way I thought we were doing it (and this is probably what you meant) is that CT is an optional addition to a Lemonade enabled server. The reason I say this is that there are quite a number of CT engines out there commercially available. We can spec an interface from the Client to the IMAP server and from the IMAP server to the CT engine. This way the CT engine can reside on a server (like an Oracle server or IBM bladed machine), while still allowing maximum throughput for all IMAP users who are doing regular accesses. There are a few rules which we will need to put in place (Threading, non-blocking client, request timeout, etc.) but these we will address when we get closer to a working spec. If the admin does not whish to add a CT server, he should be able to setup the IMAP server to either a) Not advertise the CAPABILLITY, or b) return a NO to MEDIACONVERSIONS requests. Just my 2 cents :} Corby Wilson =20 =20 > -----Original Message----- > From: lemonade-bounces@ietf.org=20 > [mailto:lemonade-bounces@ietf.org] On Behalf Of ext Mark Crispin > Sent: Monday, January 24, 2005 17:44 PM > To: Wener Michael (Nokia-ES/Pittsburgh) > Cc: lemonade@ietf.org > Subject: Re: [lemonade] LEMONADE WG Media Conversion Summary >=20 > I would like to ask for a minor clarification, and offer a strawman. >=20 > Is it anticipated that media conversion would be a facility=20 > of specialized IMAP servers? Or, alternatively, is this=20 > expected to become a more or less "mandatory to implement=20 > extension" in general purpose servers? >=20 > I am asking because server-based media conversion may be a=20 > severe burden to a general purpose server (as well as having=20 > potential security implications), and any mandate to that=20 > effect is potentially harmful.=20 > I'm not necessarily opposed, but am sounding a note of caution. >=20 > On the other hand, an extension that is focused on=20 > specialized servers, using a capability-driven mechanism,=20 > seems to be a very obvious means of addressing the issue and=20 > would have my enthusiastic support. >=20 > The assumption here is that this is a performance=20 > optimization, and not a requirement for clients to work at=20 > all. I persist in my belief that all clients should work=20 > with a base-level server without requiring any extension. >=20 > The capability mechanism need not be cumbersome; there could=20 > be a general capability for media conversions, and then an=20 > additional negotiation for the supported conversion=20 > mechanism(s). Although this likely adds an RTT, that may be=20 > less costly in the overall scheme of things. >=20 > As a strawman, suppose the server offers MEDIACONVERSIONS as=20 > an extension.=20 > There could then be a command to query as to the available=20 > conversions; or, alternatively, there could be a means by=20 > which the client offers a list of its desired set of media=20 > conversions and the server then reports the intersection=20 > between these and what the server supports. >=20 > A shortcut that avoids the extra RTT is a form of FETCH that=20 > lists the client-acceptable media conversions, and the server=20 > can then choose one and perform it in the response. One of=20 > these client-specified conversions is "no conversion", which=20 > would tell the server to send the data back unconverted=20 > rather than barf. How such a command is engineered would=20 > largely depend upon client needs. >=20 > In spite of my note of caution above, I think that this is=20 > potentially a very exciting and useful path for IMAP to take.=20 > It is one that was anticipated in IMAP from the onset. So,=20 > please treat my caution as a "do it right" rather than a=20 > "don't do it." :-) >=20 > -- Mark -- >=20 > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. >=20 > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade >=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 25 00:21:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12426 for ; Tue, 25 Jan 2005 00:21:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtJPB-0000TC-Ax for lemonade-web-archive@ietf.org; Tue, 25 Jan 2005 00:38:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtJ5B-0005ss-RU; Tue, 25 Jan 2005 00:17:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtJ4K-0005V0-UR for lemonade@megatron.ietf.org; Tue, 25 Jan 2005 00:16:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12236 for ; Tue, 25 Jan 2005 00:16:45 -0500 (EST) Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtJKx-0000MM-SE for lemonade@ietf.org; Tue, 25 Jan 2005 00:34:01 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P5GjD6009714; Mon, 24 Jan 2005 21:16:46 -0800 Received: from Shimo-Tomobiki.panda.com ([70.58.77.1]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P5Ggr9019952 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 Jan 2005 21:16:44 -0800 Date: Mon, 24 Jan 2005 21:16:39 -0800 From: Mark Crispin To: Corby.Wilson@nokia.com Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary In-Reply-To: <78E9902B779FD5428DB035B5F6A50EFB02CBA50A@daebe004.americas.nokia.com> Message-ID: References: <78E9902B779FD5428DB035B5F6A50EFB02CBA50A@daebe004.americas.nokia.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Mon, 24 Jan 2005 Corby.Wilson@nokia.com wrote: > If the admin does not whish to add a CT server, he should be able to > setup the IMAP server to either a) Not advertise the CAPABILLITY, or b) > return a NO to MEDIACONVERSIONS requests. I believe that a server which has a capability administratively disabled should not advertise that capability, rather than false state that it offers it and then return a NO. A NO should only be returned in those cases where the end user can do something useful about the problem, e.g. create the name that does not exist, etc. NO should not be used for a capability fault. I deplore the practice of certain servers to return NO to FETCH, SEARCH, etc. commands on the grounds of "not implemented". It is becoming painfully clear that a revision of RFC 3501 must explicitly forbid such behavior. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 25 03:19:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08354 for ; Tue, 25 Jan 2005 03:19:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtMBt-0006En-Qk for lemonade-web-archive@ietf.org; Tue, 25 Jan 2005 03:36:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLsh-0006QN-KF; Tue, 25 Jan 2005 03:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtLoU-0005bi-R7 for lemonade@megatron.ietf.org; Tue, 25 Jan 2005 03:12:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07987 for ; Tue, 25 Jan 2005 03:12:37 -0500 (EST) Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout2.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtM5A-0005yt-34 for lemonade@ietf.org; Tue, 25 Jan 2005 03:29:52 -0500 Received: from il-tlv-bridge02.comverse.com (il-tlv-bridge02.comverse.com [10.115.242.50]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id j0P8CTf21691; Tue, 25 Jan 2005 10:12:29 +0200 Received: from il-tlv-mail02.comverse.com ([10.115.242.26]) by il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jan 2005 10:12:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 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] LEMONADE WG Media Conversion Summary Date: Tue, 25 Jan 2005 10:12:33 +0200 Message-ID: <4389DC3E2E59694D8B01794D38C1499CEE9A74@il-tlv-mail02.comverse.com> Thread-Topic: [lemonade] LEMONADE WG Media Conversion Summary Thread-Index: AcUCZ9n9ZUWA3Y0nQieMxdNZ23hcjwAM6r4gAAXZlPA= From: "Erev Ari" To: X-OriginalArrivalTime: 25 Jan 2005 08:12:34.0822 (UTC) FILETIME=[A0187260:01C502B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: MRC@CAC.Washington.EDU, Corby.Wilson@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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Hello, I would like to relate to comments made by Mark and Corby. Mark said: > Is it anticipated that media conversion would be a facility of specialized=20 > IMAP servers? Or, alternatively, is this expected to become a more or > less "mandatory to implement extension" in general purpose servers? And Corby: > Content transformation is VERY expensinve (especially immages). An IMAP > server which does onboard content transformation will have many problems > with connection timeouts as people try to transform data. I propose that the IMAP Conversion solution, is designed in such a way that it *CAN* be Implemented by an IMAP Proxy. Note - I am not suggesting that this should be the *ONLY* implementation choice. I only suggest that the solution takes such an implementation into consideration. Although I agree upfront, that a Proxy solution has its own complications, it also has many advantages, especially when maintaining a very large system with different "life cycles" of the IMAP/Messaging server, and the media conversion requirements,=20 which are usually related to a different set of aspects (such as specific type of clients (hand-sets) and capabilities. A solution involving an IMAP proxy that handles the media conversion supports both comments from Marc and Corby: 1. It allows the use of "general purpose" IMAP servers at the back-end. 2. It off-loads the main server from the content transformation work. (even if the actual media conversion is done by an external Content Transformation server that the IMAP server talks to - it still puts a considerable burden on the=20 IMAP server to manage this interaction). This allows to cope with scalability by adding proxies (to handle the expensive media conversion) rather than upgrading the back-end IMAP servers. And I would like to add: 3. It allows a certain degree of flexibiliy to change/manage the behavior of the "media conversion" facet of the "system" with=20 minimal effect on the IMAP server itself. Ari _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Jan 25 17:59:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22448 for ; Tue, 25 Jan 2005 17:59:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtZvz-0005nr-UK for lemonade-web-archive@ietf.org; Tue, 25 Jan 2005 18:17:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtZd0-0001tS-0x; Tue, 25 Jan 2005 17:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtZXo-0000fM-88 for lemonade@megatron.ietf.org; Tue, 25 Jan 2005 17:52:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21888 for ; Tue, 25 Jan 2005 17:52:17 -0500 (EST) Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtZoa-0005Y4-L9 for lemonade@ietf.org; Tue, 25 Jan 2005 18:09:42 -0500 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.74.75]) by warlock.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id j0PMpa4F029492; Tue, 25 Jan 2005 14:51:37 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3CBC@daebe005.americas.nokia.com> References: <225A4E03D0EE5245A5C5F7E7B7C1F27A016D3CBC@daebe005.americas.nokia.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Tue, 25 Jan 2005 14:47:25 -0800 To: Michael.Wener@nokia.com, From: Randall Gellens Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 At 5:51 PM -0600 1/24/05, Michael.Wener@nokia.com wrote: > Any additional RTT could be lessened by allowing the client to > gain this information at times of it's choosing, and making it > apply generally, i.e. to any specific body part as long as that > body part was of the correct content type. If the mechanism does add an extra RTT, the client should be able to cache the information to be able to save the RTT in similar future cases. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It takes a wonderful brain and exquisite senses to produce a few stupid ideas. --Santayana _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Jan 26 00:48:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22123 for ; Wed, 26 Jan 2005 00:48:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtgJi-0001dB-81 for lemonade-web-archive@ietf.org; Wed, 26 Jan 2005 01:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctfxo-0003RT-Ng; Wed, 26 Jan 2005 00:43:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtfvN-00032D-Ce for lemonade@megatron.ietf.org; Wed, 26 Jan 2005 00:41:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21825 for ; Wed, 26 Jan 2005 00:41:02 -0500 (EST) From: Corby.Wilson@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtgCD-0001SW-FA for lemonade@ietf.org; Wed, 26 Jan 2005 00:58:30 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0Q5es828708; Wed, 26 Jan 2005 07:40:55 +0200 (EET) X-Scanned: Wed, 26 Jan 2005 07:40:49 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j0Q5enIA011925; Wed, 26 Jan 2005 07:40:49 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00o1SkyT; Wed, 26 Jan 2005 07:39:45 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j0Q5dhU21156; Wed, 26 Jan 2005 07:39:44 +0200 (EET) Received: from daebe004.NOE.Nokia.com ([10.241.35.104]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 25 Jan 2005 23:39:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] LEMONADE WG Media Conversion Summary Date: Tue, 25 Jan 2005 23:39:42 -0600 Message-ID: <78E9902B779FD5428DB035B5F6A50EFB02CBA720@daebe004.americas.nokia.com> Thread-Topic: [lemonade] LEMONADE WG Media Conversion Summary thread-index: AcUCnV2gM/zbi2rFR0qOj8GQsd9qHwAy87Dw To: X-OriginalArrivalTime: 26 Jan 2005 05:39:43.0348 (UTC) FILETIME=[6FE25340:01C50369] X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable I agree COMPLETELY. I don't like NO for this purpose and would rather see the CT server advertised as a CAPABILTY. Corby=3D P.S.: Mark, if you support a rewrite of 3501 to fix NO, I'm all for it :)=3D) =20 > -----Original Message----- > From: mrc@ndcms.cac.washington.edu=20 > [mailto:mrc@ndcms.cac.washington.edu] On Behalf Of ext Mark Crispin > Sent: Tuesday, January 25, 2005 00:17 AM > To: Wilson Corby (Nokia-ES/Pittsburgh) > Cc: Wener Michael (Nokia-ES/Pittsburgh); lemonade@ietf.org > Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary >=20 > On Mon, 24 Jan 2005 Corby.Wilson@nokia.com wrote: > > If the admin does not whish to add a CT server, he should=20 > be able to=20 > > setup the IMAP server to either a) Not advertise the=20 > CAPABILLITY, or=20 > > b) return a NO to MEDIACONVERSIONS requests. >=20 > I believe that a server which has a capability=20 > administratively disabled should not advertise that=20 > capability, rather than false state that it offers it and=20 > then return a NO. >=20 > A NO should only be returned in those cases where the end=20 > user can do something useful about the problem, e.g. create=20 > the name that does not exist, etc. NO should not be used for=20 > a capability fault. >=20 > I deplore the practice of certain servers to return NO to=20 > FETCH, SEARCH, etc. commands on the grounds of "not=20 > implemented". It is becoming painfully clear that a revision=20 > of RFC 3501 must explicitly forbid such behavior. >=20 > -- Mark -- >=20 > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. >=20 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 31 13:52:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06807 for ; Mon, 31 Jan 2005 13:52:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvgxF-0003Mg-PQ for lemonade-web-archive@ietf.org; Mon, 31 Jan 2005 14:11:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvgaC-0005T9-LF; Mon, 31 Jan 2005 13:47:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvgYK-00059N-Aw for lemonade@megatron.ietf.org; Mon, 31 Jan 2005 13:45:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05543 for ; Mon, 31 Jan 2005 13:45:33 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvgqJ-000392-B9 for lemonade@ietf.org; Mon, 31 Jan 2005 14:04:12 -0500 Received: from [172.16.2.110] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 31 Jan 2005 18:44:48 +0000 Message-ID: <41FE7CA0.2010003@isode.com> Date: Mon, 31 Jan 2005 18:44:48 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org Subject: [lemonade] Re: Planning for meeting in Minneapolis 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > Alexey needs to propose what changes to make to CondStore, as a > concrete written proposal to the list. I've just submitted a new draft that describes how CONDSTORE modification sequences can be used to track expunged messages. Before it is announced, people can find it at: http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt I will welcome all suggestions, especially on issues marked with <<>> in the document. I can rework RECONNECT to reference the new document, if people feel it is a good idea. Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Jan 31 17:23:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12383 for ; Mon, 31 Jan 2005 17:23:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkFX-0004QH-Ld for lemonade-web-archive@ietf.org; Mon, 31 Jan 2005 17:42:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjIX-0002KV-SD; Mon, 31 Jan 2005 16:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CviWq-0006xo-Vx for lemonade@megatron.ietf.org; Mon, 31 Jan 2005 15:52:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19390 for ; Mon, 31 Jan 2005 15:52:11 -0500 (EST) Received: from kone17.procontrol.vip.fi ([212.149.71.178] helo=danu.procontrol.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvioq-00064l-Qp for lemonade@ietf.org; Mon, 31 Jan 2005 16:10:50 -0500 Received: by danu.procontrol.fi (Postfix, from userid 106) id 213171C134FD; Mon, 31 Jan 2005 22:51:39 +0200 (EET) Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 1AE6F1C15336; Mon, 31 Jan 2005 22:51:34 +0200 (EET) From: Timo Sirainen To: Alexey Melnikov In-Reply-To: <41FE7CA0.2010003@isode.com> References: <41FE7CA0.2010003@isode.com> Date: Mon, 31 Jan 2005 22:51:33 +0200 Message-Id: <1107204693.12365.238.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IMAP Extensions WG , lemonade@ietf.org Subject: [lemonade] expunged draft 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="===============2124534334==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --===============2124534334== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-GKQMz1/DmeuHdswXxMKD" --=-GKQMz1/DmeuHdswXxMKD Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable On Mon, 2005-01-31 at 18:44 +0000, Alexey Melnikov wrote: > I've just submitted a new draft that describes how CONDSTORE=20 > modification sequences can be used to track expunged messages. Before it=20 > is announced, people can find it at: > http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt >=20 > I will welcome all suggestions, especially on issues marked with <<>> in=20 > the document. It shows that HIGHESTMODSEQ update is sent after EXPUNGE command. What about when other session did the EXPUNGE and we're seeing untagged EXPUNGEs? Maybe always send it after untagged expunges (and don't mention EXPUNGE command at all)? Servers supporting UNSELECT should most likely also send HIGHESTMODSEQ just as with CLOSE, but this isn't mentioned. And what about with SELECT? Maybe just point out more generally that "when using a command which closes the mailbox, send HIGHESTMODSEQ". Perhaps LOGOUT should do that too? <> Yes, I think so. In 3.4 EXPUNGED Response it seems rather useless trying to rewrite what RFC3501 says about EXPUNGEs. Just point out that it works exactly as normal untagged EXPUNGE? It would be really bad if they accidentally got different rules. Maybe rename the EXPUNGED to UIDEXPUNGE or similar to make it more clear that it's sending UIDs and not sequences? --=-GKQMz1/DmeuHdswXxMKD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB/ppVyUhSUUBViskRAqqEAJ0Ucz64EXOhOGG10azlhH9EY68lNQCeI6Z7 95t0GeoUZ6F8We/XDhLn0yI= =CTeH -----END PGP SIGNATURE----- --=-GKQMz1/DmeuHdswXxMKD-- --===============2124534334== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============2124534334==-- From lemonade-bounces@ietf.org Mon Jan 31 20:39:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05107 for ; Mon, 31 Jan 2005 20:39:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvnJB-0001TU-T4 for lemonade-web-archive@ietf.org; Mon, 31 Jan 2005 20:58:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvn0C-0005Wm-HT; Mon, 31 Jan 2005 20:38:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvmwT-0004pg-Qj for lemonade@megatron.ietf.org; Mon, 31 Jan 2005 20:34:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04710 for ; Mon, 31 Jan 2005 20:34:56 -0500 (EST) Received: from kahuna.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvnEW-0001N6-KV for lemonade@ietf.org; Mon, 31 Jan 2005 20:53:37 -0500 X-Envelope-From: lisa@osafoundation.org X-Envelope-To: lemonade@ietf.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j111Yqaa010091 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 31 Jan 2005 17:34:52 -0800 In-Reply-To: <41FE7CA0.2010003@isode.com> References: <41FE7CA0.2010003@isode.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [lemonade] Re: Planning for meeting in Minneapolis Date: Mon, 31 Jan 2005 17:34:45 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org, IMAP Extensions 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: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit So, does this mean that we don't need to yank CondStore out of the RFC queue? thanks, Lisa On Jan 31, 2005, at 10:44 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > >> Alexey needs to propose what changes to make to CondStore, as a >> concrete written proposal to the list. > > I've just submitted a new draft that describes how CONDSTORE > modification sequences can be used to track expunged messages. Before > it is announced, people can find it at: > http://ietf.webdav.org/imapext/draft-melnikov-imap-expunged-00.txt > > I will welcome all suggestions, especially on issues marked with <<>> > in the document. > > I can rework RECONNECT to reference the new document, if people feel > it is a good idea. > > Alexey > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade